System and method for establishing and providing access to an online account

ABSTRACT

A method of providing an account is provided. The method includes receiving identification information associated with a user during a communication session. The method further includes communicating a request for credit information, wherein the request includes at least a portion of the identification information. The requested credit information is received and an account is approved based at least in part on the received credit information. The account is opened and access is provided to the opened account during the communication session.

RELATED APPLICATIONS

This application is related to and claims the benefit of U.S.Provisional Application No. 60/471,744 filed May 15, 2003.

TECHNICAL FIELD OF THE INVENTION

This invention relates in general to online accounts and, moreparticularly, to a system and method for establishing and providingaccess to an online account.

BACKGROUND OF THE INVENTION

The Internet and the increasing availability of broadband services hasled to the proliferation of online gambling, including online sportsbetting. In general, to participate in online gambling activities, suchas placing bets on sporting events, a user must open an account with anonline gambling service, which is typically a deposit or credit account.Once the user's account is open and funded, the user may participate inonline gambling activities using the funds or balance available in hisor her account. Over time, the user may deposit additional funds into,or withdraw funds from, his or her account.

To establish an account with an online gambling service, a usertypically completes an account application, which must be approved bythe online gambling service. For a deposit account, the user typicallycompletes an online account application and funds the account through acredit card transaction with the online gambling service or byphysically mailing a check, cash, or similar payment to the onlinegambling service. For a credit account, the user may be required to mailparticular items, such as a credit card or bank statement for example,to the online gambling service in order for the gambling service todetermine whether to approve the account application. Such mailingsintroduce delays into the account opening process, which may discouragepotential users from opening an account with the gambling service.

SUMMARY OF THE INVENTION

According to one embodiment, a method of providing an account isprovided. The method includes receiving identification informationassociated with a user during a communication session. The methodfurther includes communicating a request for credit information, whereinthe request includes at least a portion of the identificationinformation. The requested credit information is received and an accountis approved based at least in part on the received credit information.The account is opened and access is provided to the opened accountduring the communication session.

According to another embodiment, a system for providing an account isprovided. The system includes a processor and a memory. The processor isoperable to receive identification information associated with a userduring a communication session and communicate a request for creditinformation, wherein the request includes at least a portion of theidentification information. The processor is further operable to receivethe requested credit information and approve an account based at leastin part on the received credit information. The processor is furtheroperable to open the approved account and provide access to the openedaccount during the communication session. The memory is operable tostore the opened account.

According to yet another embodiment, another method of providing anaccount is provided. The method includes electronically receiving creditinformation regarding a user, approving an account based at least inpart on the electronically received credit information, opening theaccount, and providing access to the opened account.

Various embodiments of the present invention may benefit from numerousadvantages. It should be noted that one or more embodiments may benefitfrom some, none, or all of the advantages discussed below.

One advantage of the invention is that a trading platform may beoperable to activate a new account for a prospective user in real timeor substantially in real time. For example, if a prospective userrequests a new account during an Internet session between a client usedby the prospective user and the trading platform, the trading platformmay approve the account for the prospective user and open the accountsuch that the user may access the account and/or begin trading activityduring the same Internet session with the trading platform. In someembodiments, the trading platform is operable to activate a creditaccount (or at least an account having a credit component) for aprospective user in real time or substantially in real time, such asduring an Internet session as described above. Thus, a prospective usermay access a web site associated with the trading platform, apply for acredit account, have the account approved quickly, login using theopened credit account, and begin trading activity on the tradingplatform, all in one communication session (such as an Internet session,for example) with the trading platform.

Another advantage of the invention is that a trading platform may beoperable to determine whether to approve each of a variety of types ofaccounts, and to activate at least one approved type of account, for aprospective user in real time or substantially in real time. Forexample, if a prospective user requests a new account during an Internetsession between a client used by the prospective user and the tradingplatform, the trading platform may determine whether to approve each ofa variety of types of accounts for the prospective user, receive aselection from the user, of one of the approved types of accounts andopen the selected type of account for the user such that the user mayaccess the account and/or begin trading activity during the sameInternet session with the trading platform. Such types of accounts mayinclude, for example, a deposit account, a credit account, a hybriddeposit/credit account, and a stop-loss account.

The trading platform may determine whether to approve each type ofaccount based on credit information regarding the user (such as a creditscore, an identity score and/or other credit information for example)received from one or more credit verification entities, such as creditbureaus. The trading platform may apply a decision matrix and/or otherbusiness rules to the credit information to determine whether to approveeach type of account for the user.

In some embodiments, by determining whether to approve each of a varietyof types of accounts for prospective users, the trading platform maydetermine an appropriate credit limit or other initial account balances(and/or other account parameters) to grant each user based on theperceived credit risk of that user (according to received creditinformation regarding the user), which may reduce the amount ofuncollected debts owed by users to trading platform.

Yet another advantage is that a trading platform may be operable todetermine a risk value for an order to trade a particular bettingproduct, which may be an estimate of the likely maximum loss that theuser making the order could experience if the order is matched (in otherwords, if the bet is executed). The risk value may be based at least onthe size, or unit stake, of the order and a risk factor determined forthe particular betting product. The risk factor may be based at least onhistorical data regarding the type of the particular betting product.

The risk value for an order, which represents an estimated maximum lossthat the user could experience, may be different than the actual maximumloss that the user could experience. For example, the actual maximumamount that a user could lose on an order to trade a betting product maybe $950, whereas the risk value for that order may be $700. The tradingplatform may determine whether to allow a user to place particularorders based on the risk values determined for such orders and one ormore current balances in the user's account. Since the risk value for anorder may be less than the actual maximum amount that the user couldlose on the order, the trading platform may allow a user to place ordersthat would not be allowed by previous betting moderators, resulting inincreased liquidity and thus increased profits for the trading platform.

Still another advantage is that the risk value of a user's executedorder may be updated during the event or events underlying the order. Asa result, one or more current balances in the user's account may beupdated accordingly. In addition, the size of other unexecuted ordersplaced by the user may be adjusted based on the updated risk value ofthe executed order. Such updates may result in additional increasedliquidity and thus increased profits for the trading platform.

Still another advantage is that a trading platform may act as anintermediary for effecting transactions between various users of thetrading platform. For example, the trading platform may createobligations and execute a separate transaction with each user involvedin a trade, thus giving each user the appearance of transacting directlywith the other user. In this manner, the trading platform may be said toeffectuate a “virtual” transaction between the users involved in eachtrade. By creating obligations and executing a separate transaction witheach user involved in a trade, rather than facilitating a direct tradebetween the users, the trading platform may be able to manage theobligations created for each user independently. For example, if a firstuser in a trade fails to make a payment regarding the trade, the tradingexchange may make the payment to the second user, essentially on behalfof the first user, and separately attempt to collect the payment fromthe first user. In this manner, a user who is owed a payout due to asuccessful trade may be assured of receiving the payout. In otherembodiments, the trading platform may facilitate direct trades betweenusers.

Other advantages will be readily apparent to one having ordinary skillin the art from the following figures, descriptions, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and forfurther features and advantages, reference is now made to the followingdescription, taken in conjunction with the accompanying drawings, inwhich:

FIGS. 1A and 1B illustrate one embodiment of a system for providingaccounts to users for participation in a trading platform;

FIG. 2 illustrates an example operation of the system of FIGS. 1A and 1Bin accordance with one embodiment of the present invention;

FIG. 3 illustrates one embodiment of an approval decision matrix thatmay be used to make account approval determinations for prospectiveusers of the trading platform of FIGS. 1A and 1B;

FIGS. 4A and 4B illustrate an example embodiment of a set of rules foruse in conjunction with the approval decision matrix of FIG. 3 to makeaccount approval determinations;

FIGS. 5A though 5E illustrate an example methodology, as well as theapplication of the methodology for a variety of scenarios, fordetermining whether to approve a requested trading order in accordancewith one embodiment of the present invention;

FIG. 6 illustrates an embodiment of an account database comprising anynumber of accounts used in the trading platform of FIGS. 1A and 1B;

FIG. 7 illustrates an embodiment of an open order database comprisingany number of open trading orders placed on the trading platform ofFIGS. 1A and 1B;

FIG. 8 illustrates one embodiment of a method for providing accounts tousers for participation in a trading platform;

FIG. 9 illustrates one embodiment of a method for trading bettingproducts via the trading platform of FIGS. 1A and 1B;

FIG. 10 illustrates the trading platform of FIGS. 1A and 1B acting as anintermediary between users involved in a trade in accordance with anembodiment of the present invention; and

FIG. 11 illustrates an example method of using the trading platform ofFIGS. 1A AND 1B as an intermediary between users involved in a trade inaccordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS OF THE INVENTION

FIGS. 1A and 1B illustrate one embodiment of a system 10 thatfacilitates establishing accounts used for performing any suitablefinancial transaction. System 10 includes a communications network 100,one or more clients 104, one or more credit verification entities 106,and a trading platform 20. Trading platform 20 includes one or moreservers 108, one or more operator terminals 110, a communicationsnetwork 112 and a trading engine 114. Other architectures and componentsof system 10, including various architectures and components of tradingplatform 20, may be used without departing from the scope of thisdisclosure.

In general, trading platform 20 provides users of clients 104 withtrading accounts 154 that may be used for trading betting products 150,for example, with other users of clients 104. Trading engine 114provides services such as, for example, approving and opening useraccounts, managing available funds or account balances for users,establishing risk factors for betting products 150, placing tradingorders 152, and matching trading orders 152 to execute trades. Tradingengine 114 may perform other functions or provide other services withoutdeparting from the scope of this disclosure.

It should be understood that although the following discussion oftrading platform 20 focuses on trading accounts 154 and trading bettingproducts 150, in alternative embodiments, trading platform 20 may beused for trading any suitable type of product, such as financialproducts, contract, or merchandise, for example. In such embodiments,betting products 150 may be supplemented with or replaced by anysuitable type of product or products. Similarly, trading platform 20 maybe used to open any suitable type of account 154. Moreover, tradingplatform 20 may be any other entity suitable to provide accounts tovarious users, such as a financial institution or an online merchant,for example. Trading platform 20 may also be referred to as accountprovider 20.

Communications network 100 couples and facilitates wireless or wirelinecommunication between clients 104, credit verification entities 106 andservers 108. Communications network 100 may, for example, communicateInternet Protocol (IP) packets, Frame Relay frames, AsynchronousTransfer Mode (ATM) cells, voice, video, data, and other suitableinformation between network addresses. Communications network 100 mayalso communicate data via wireless communications, such as by WirelessApplication Protocol (WAP) standard protocols, including 802.11,third-generation (3G) protocols (such as W-CDMA or CDMA 2000, forexample), or Global System for Mobile Communications (GSM) protocols,for example. Communications network 100 may include one or more localarea networks (LANs), radio access networks (RANs), metropolitan areanetworks (MANs), wide area networks (WANs), interactive televisionnetworks, all or a portion of the global computer network known as theInternet, and/or any other communication system or systems at one ormore locations.

Clients 104 may comprise computer systems that include appropriate inputdevices, output devices, mass storage media, processors, memory, orother components for receiving, processing, storing, and/orcommunicating information with other components of system 10. As used inthis document, the term “computer” is intended to encompass a personalcomputer, workstation, network computer, wireless data port, wirelesstelephone, personal digital assistant (PDA), cellular telephone, one ormore processors within these or other devices, or any other suitableprocessing device. It will be understood that any number of clients 104may be coupled to communications network 100. Clients 104 are generallyoperated by users to trade products, such as betting products 150, forexample, using trading platform 20.

As shown in FIG. 1A, a particular client 104 may comprise a browserapplication 116, such as an Internet web browser, for example. Browserapplication 116 may allow a user of client 104 to navigate through, or“browse,” various Internet web sites or web pages. Client 104 may alsocomprise one or more graphics applications 118, such as a FLASH™application for example, operable to display various types of datareceived via communications network 100, such as graphics, video, andstreaming data (such as video and/or audio), for example.

Credit verification entities 106 are generally operable to collect,organize and analyze credit and identification information regardingconsumers, and to provide such information and/or various evaluations ofsuch information, such as credit scores and/or identificationauthentication scores, to trading platform 20. Credit and identificationinformation may include credit history information, payment information,personal information regarding occupation, income, home ownership, etc.,and any other suitable information. As an example only and not by way oflimitation, credit verification entities 106 may include credit bureaus,such as EXPERIAN, TRANS UNION, EQUIFAX, or any other entities suitableto collect, organize and/or analyze credit information regardingprospective or current users of system 10.

As discussed above, trading platform 20 includes servers 108, operatorterminals 110, communications network 112 and trading engine 114.Communications network 112 couples and facilitates wireless or wirelinecommunication between servers 108, operator terminals 110 and tradingengine 114. Communications network 112 may, for example, communicateInternet Protocol (IP) packets, Frame Relay frames, AsynchronousTransfer Mode (ATM) cells, voice, video, data, and other suitableinformation between network addresses. Communications network 112 mayalso communicate data via wireless communications, such as by WirelessApplication Protocol (WAP) standard protocols, including as 802.11,third-generation (3G) protocols (such as W-CDMA or CDMA 2000, forexample), or Global System for Mobile Communications (GSM) protocols,for example. Communications network 112 may include one or more localarea networks (LANs), radio access networks (RANs), metropolitan areanetworks (MANs), wide area networks (WANs), interactive televisionnetworks, all or a portion of the global computer network known as theInternet, and/or any other communication system or systems at one ormore locations. In various embodiments, communications networks 100 and112 may be partially or totally separate networks, partially overlappingnetworks, or the same networks. In a particular embodiment,communications network 100 is a public network, such as the Internet,while communications network 112 is a private or restricted-accessnetwork.

In the example embodiment shown in FIGS. 1A and 1B, trading engine 114comprises one or more core servers 120 and a database server 122.Database server 122 includes one or more databases 124 operable to storevarious data 156 associated with trading platform 20, such asinformation regarding users, clients 104, operators, operator terminals110, and betting products 150, for example. Databases 124 may alsocomprise one or more approval decision matrices 170 and sets of otherbusiness rules 180, as discussed in greater detail below. In addition,one or more databases 124 may comprise an account database 190 includingdata regarding various trading accounts 154 (for example, see FIG. 6),such as data regarding various initial balances 158 and current balances160 for each of a number of trading accounts 154, for example. Further,one or more databases 124 may comprise an open order database 192including information regarding betting products 150 and/or varioustrading orders 152 (for example, see FIG. 7). Database server 122 maycommunicate with core servers 120 such that core servers 120 may storeinformation, retrieve information, and share information with eachother. Database server 122 may provide a backup in the case of outagesor other failures of various components of trading platform 20.

Each core server 120 includes one or more function modules 126 that mayprovide particular functionality associated with system 10. Tradingengine 114 may include any number of core servers 120, each of which mayprovide some or all of the functionality of one or more other coreservers 120. In this manner, core servers 120 may share the processingload as well as provide partial or complete redundancy for performingthe various functionalities associated with function modules 126, whichmay be useful in the case of outages or other failures of particularcore servers 120 or components thereof.

As an example only and not by way of limitation, a function module 126may provide functionality associated with verifying the identity and/orcredit of prospective users; determining whether to approve one or moretypes of trading accounts 154 for prospective users; opening and/oractivating trading accounts 154; managing available funds or balances invarious trading accounts 154; managing betting products 150; andmanaging trading orders 152 to trade betting products 150, for example.A function module 126 may be called by another component of tradingplatform 20, such as a server 108 or operator terminal 110, for example,and in response, provide the particular functionality associated withthat function module 126. Each function module 126 comprises anysuitable combination of hardware and software in trading engine 114 toprovide the described function or operation of that function module 126.For example, function modules 126 may include program instructions, aswell as the associated memory and processing components to execute theprogram instructions.

The representation of the various function modules 126 shown in FIGS. 1Aand 1B may be a logical, rather than physical, representation of thevarious functionalities provided by trading engine 114. Thus, variousfunction modules 126 may be separate or at least partially combined orintegral to other function modules 126. Thus, in some embodiments, oneor more function modules 126 may be physically distributed such thateach function module 126, or multiple instances of each function module126, may be located in a different physical location geographicallyremote from each other. In other embodiments, one or more functionmodules 126 may be combined and/or integral to each other. For example,a particular set of computer code may include any number of interrelatedor integral function modules 126.

As discussed above, function modules 126 are generally operable toperform various functions in the operation of trading platform 20. Inthe embodiment shown in FIG. 1, function modules 126 include a creditand identity verification module 130, an account approval module 132, anaccount establishment module 134, a balance management module 136, aproduct management module 138, an order management module 140, and atrade management module 142. Credit and identity verification module130, account approval module 132, and account establishment module 134are generally operable to perform account opening functions, includingobtaining information regarding potential users, determining whether toapprove trading accounts 154 for such users, and opening approvedtrading accounts 154. Balance management module 136 is generallyoperable to manage one or more various balances available for tradingactivity for each of a number of trading accounts 154 associated withtrading platform 20. Product management module 138 and order managementmodule 140 are generally operable to perform risk management functions,including determining risk factors 330 and risk values 332 for variousbetting products 150 and trading orders 152, respectively, anddetermining whether to allow users to place particular trading orders152 based at least on the risk values 332 of such trading orders 152.Trade management module 142 is generally operable to match tradingorders 152 in order to execute trades.

Trading engine 114 further comprises a memory that may be accessed orotherwise utilized by one or more components of trading engine 114. Thememory may take the form of volatile or non-volatile memory including,without limitation, magnetic media, optical media, random access memory(RAM), read-only memory (ROM), removable media, or any other suitablelocal or remote memory component. Such memory may be separate from orintegral to other memory devices in trading platform 20. In general, thememory may store various account information, trading information, andproduct information in any suitable format including, for example, XMLtables, flat files, comma-separated-value (CSV) files, SQL tables,relational database tables, objects, and others.

Servers 108 are generally operable to provide an interface betweenclients 104 and trading platform 20. One or more servers 108 may be webapplication servers or processors operable to allow users of clients 104to participate in trading platform 20 via the Internet using a standarduser interface language such as, for example, the HyperText MarkupLanguage (HTML). One or more servers 108 may be separate from orintegral with trading engine 114. In addition, in some embodiments, oneor more servers 108 may be physically distributed such that each server108, or multiple instances of each server 108, may be located in adifferent physical location geographically remote from each other and/orfrom trading engine 114. In other embodiments, one or more servers 108may be combined and/or integral to each other. One or more servers 108may be implemented using a general purpose personal computer (PC), aMacintosh, a workstation, a UNIX-based computer, a server computer, orany other suitable processing device.

In some embodiments, servers 108 are operable to provide security and/orauthentication of users or other persons or entities attempting toaccess trading platform 20. For example, servers 108 may essentiallyprovide a firewall for entities attempting to access trading platform20. In addition, servers 108 may be operable to translate one or moredata protocols used by trading engine 114 with one or more protocolsused by applications hosted by one or more clients 104. In particularembodiments, servers 108 may be operable to translate a particular dataprotocol used by trading engine 114 with a particular protocol that canbe understood by graphics application 118 (such as a FLASH™ application,for example) hosted by one or more clients 104.

In particular embodiments, one or more servers 108 are web applicationservers operable to communicate dynamically updated information toparticular clients 104 via communications network 100. For example, oneor more servers 108 may communicate dynamically updated informationregarding activities occurring on trading platform 20 to particularclients 104 via communications network 100. In some embodiments, one ormore servers 108 communicate notifications and/or other suitableinformation when trading orders 152 are placed and/or matched (in otherwords, when trades are executed) in real time or substantially in realtime to particular clients 104 identified as interested in such tradingorders 152. Servers 108 communicate such notifications and/or othersuitable information to clients 104 via e-mail or by one or moredynamically updated web pages, for example.

In particular embodiments, when a new trading order 152 is placed ontrading platform 20, trading engine 114 stores the trading order 152 inone or more databases, which may include databases 124, and broadcastsan update regarding the new trading order 152 to particular interestedentities. Such interested entities may include one or more operatorterminals 110 that need to know about the new trading order 152 for theproper operation of trading platform 20, as well as one or more servers108 which may communicate the update to one or more clients 104identified as being interested in that update. For example, one or moreservers 108 may broadcast to one or more particular clients 104 anupdated web page which notifies such clients 104 of the new tradingorder 152 or executed trade.

Operator terminals 110 are generally operable to provide operators oftrading platform 20 access to trading engine 114 via communicationsnetwork 112. Operators of trading platform 20 may include systemadministrators, trading brokers for users of trading platform 20 (whichmay include telephone brokers, for example), traders operable to tradebetting products 150 on trading platform 20 on behalf of tradingplatform 20 itself and/or any other entity suitable to have access toall or particular aspects of the internal operations of trading platform20.

Operator terminals 110 may comprise computer systems that includeappropriate input devices, output devices, mass storage media,processors, memory, or other components for receiving, processing,storing and/or communicating information with other components of system10. It will be understood that there may be any number of operatorterminals 110 coupled to communications network 112.

One or more operator terminals 110 may comprise a graphical userinterface (GUI) application 146 which may be used to communicateinformation to clients 104 and/or users of clients 104 via communicationnetwork 100. For example, if a user or client 104 makes a request forparticular information from an operator, the operator may use GUIapplication 146 to communicate the requested information to tradingengine 114, which may forward the information to the requesting user orclient 104 via communications network 100.

In operation, during a communication session between a client 104 andtrading platform 20, trading platform 20 allows a user of client 104 toapply online for one or more types of trading accounts 154, determineswhether to approve or deny each of the one or more types of tradingaccounts 154 (or refers the user to an operator of trading platform 20for further instructions), and opens at least one of the approvedtrading accounts 154 for the user. Trading platform 20 grants the useraccess to the newly opened trading account 154 during the samecommunication session between client 104 and trading platform 20 inwhich the application for the trading account 154 was made. Such acommunication session is indicated by bi-directional path 148 shown inFIG. 1A.

Communication session 148 comprises any suitable communication sessionbetween a client 104 and trading platform 20 via communications network100. For example only and not by way of limitation, communicationsession 148 may comprise communications using web applications, e-mail,file transfer protocol (FTP), wireless application protocol (WAP),telephone, facsimile, or any other suitable means of communicating databetween a client 104 and trading platform 20. Thus, communicationsession 148 may include a web-based session in which a user uses browser116 hosted by a client 104 to navigate through various web sites or webpages associated with trading platform 20. Communication session 148 mayinclude one or more relatively brief interruptions, such as to start orrestart an application or an instance of an application (such as browserapplication 116 or graphics application 118, for example), or in thecase of a web-based communication session 148, to temporarily visit oneor more web sites or web pages not related to trading platform 20, forexample.

Thus, a prospective user of trading platform 20 may apply for a tradingaccount 154, which may comprise a credit account or an account includinga credit component, have the trading account 154 approved and opened,and begin various trading activities using the new trading account 154,all during a single communication session 148 and/or in a relativelyshort period of time. Thus, the prospective user need not mail anyinformation (such as identification information or credit information,for example) to trading platform 20 when applying for a trading account154, which is commonly required by traditional account providers. As aresult, prospective users do not have to experience the significantdelays associated with opening accounts with traditional accountproviders, such as delays associated with mailing information to or fromthe account provider.

As mentioned above, after a user's trading account 154 has been approvedand opened, the user may begin a variety of trading activities. Forexample, the user may make requests to place trading orders 152 to tradevarious betting products 150. As discussed below in greater detail,trading platform 20 may determine a risk value 332 for each tradingorder 152, which may be an estimate of the likely maximum loss that theuser making the order could experience if that trading order 152 ismatched (in other words, if the trade is executed). Trading platform 20may determine whether to allow the user to place trading orders 152based on the risk values 332 determined for such trading orders 152 andone or more current balances in the user's trading account 154. In somecases, the risk values 332 determined for particular trading orders 152are lower than the maximum possible loss that the user could lose ifsuch trading orders 152 were executed. As a result, as described belowin greater detail, the use of such risk values 332 may allow the user toplace more trading orders 152 than would otherwise be allowed, resultingin increased, liquidity and thus increased profits for trading platform20.

As discussed above, various functions of trading platform 20, such asthose mentioned above, may be performed by or using one or more of thefunction modules 130 through 142 shown in FIG. 1B. For example, accountopening functions may generally be performed by credit and identityverification module 130, account approval module 132, and accountestablishment module 134. Balance and/or funds management functions maygenerally be performed by balance management module 136. Risk managementfunctions, such as determining risk factors 330 and risk values 332 forbetting products 150 and trading orders 152, and determining whether towhether to allow users to place particular trading orders 152, maygenerally be performed by product management module 138 and ordermanagement module 140. Finally, the execution of trades may generally beperformed by trade management module 142.

Opening Accounts

Credit and identity verification module 130 is generally operable tocommunicate with one or more credit verification entities 106 in orderto obtain information regarding particular users, such as creditinformation 308 regarding such users, that may be used by accountapproval module 132 in determining whether to approve various types oftrading accounts 154 for such users, as described in greater detailbelow with reference to FIG. 2. In some embodiments, credit and identityverification module 130 is generally operable to receive identificationinformation regarding a particular user and communicate a request to oneor more credit verification entities 106 for credit informationregarding the particular user based on the user's identificationinformation. For example, a prospective user attempting to open anonline trading account 154 with trading platform 20 may enter variousidentification information (such as the prospective user's name,address, social security number, employment information, and financialinformation, for example) into one or more web pages associated withtrading platform 20. Credit and identity verification module 130communicates a request for credit information from one or more creditverification entities 106. The request may include at least a portion ofthe identification information received from the prospective user, aswell as the type or types of requested credit information. One or moreof the credit verification entities 106 may then identify, or attempt toidentify, the prospective user based on the identification informationincluded in the request, retrieve credit information regarding theprospective user, and communicate the retrieved credit information totrading platform 20. Credit and identity verification module 130receives the credit information from the one or more credit verificationentities 106.

Account approval module 132 is generally operable to determine whetherto approve, deny, or otherwise manage requests from prospective users toopen trading accounts 154 with trading platform 20. Account approvalmodule 132 may make such determinations based at least in part on creditinformation received by credit and identity verification module 130 fromcredit verification entities 106. For example, as discussed below ingreater detail with regard to FIGS. 2 and 3, a particular creditverification entity 106 may provide credit and identity verificationmodule 130 with an identity score, a credit score and/or one or morecredit information details regarding a prospective user who is applyingfor a trading account 154 with trading platform 20. Account approvalmodule 132 may then determine whether to approve, deny, or otherwisehandle the application for the trading account 154 based at least inpart on this received credit information regarding the prospective user.

In some embodiments in which trading platform 20 provides more than onetype of trading account 154, such as a deposit account, a creditaccount, a stop-loss account and/or a hybrid account, for example,account approval module 132 makes approval determinations for each typeof trading account 154 for a prospective user based at least in part onthis received credit information regarding the prospective user. Forexample, based on received credit information 308 regarding theprospective user, account approval module 132 may approve for theprospective user a deposit account and a hybrid deposit/credit account,but deny the prospective user a pure credit account. In particularembodiments, as discussed in greater detail with respect to FIG. 3,account approval module 132 may apply an approval decision matrix 170 tocredit information 308 received from a credit verification entity 106regarding a prospective user in order to make account approvaldeterminations for the prospective user.

In such embodiments in which trading platform 20 provides more than onetype of trading account 154, account approval module 132 may communicateto a prospective user (such as via e-mail or an appropriate web page,for example) the particular types of trading accounts 154 for which theprospective user is approved and/or denied. Account approval module 132receives a selection from the prospective user of one or more approvedtypes of trading accounts 154 that the prospective user would like toopen. For example, account approval module may communicate a web page toa prospective user identifying the types of trading accounts 154 forwhich the prospective user is approved, and the prospective user maythen select, using browser application 116, one of the approved tradingaccounts 154 to be opened.

Account establishment module 134 is generally operable to perform thefunctions necessary to establish, or open, trading accounts 154 forprospective users of trading platform 20. For example, for an approvedtrading account 154 that the prospective user wishes to have opened,account establishment module 134 may create the trading account 154,including creating a set of account identification data 322 for thetrading account 154, which may include, for example, a user ID 324, auser password 326, and an account number for the new account, asdiscussed below with reference to FIG. 2. Account establishment module134 communicates such account identification data 322 to the prospectiveuser via communications network 100 (such as via e-mail, for example),as discussed below with reference to FIG. 2.

In particular embodiments, account establishment module 134 activatesthe new trading account 154 in real time or substantially in real time.For example, if a prospective user requests a new trading account 154during a communication session between a client 104 and trading platform20 (such as communication session 148, for example), account approvalmodule 132 may approve the trading account 154 for the prospective userand account establishment module 134 may activate the trading account154 such that the user may access the trading account 154 and/or begintrading activity during the same communication session in which therequest for the trading account 154 was made.

Managing Available Balances

Balance management module 136 is generally operable to manage one ormore balances associated with each trading account 154 provided bytrading platform 20. Managing such balances may include determininginitial balances and/or limits 158 and managing current balances 160over time.

Initial balances and/or limits 158 may include, for example, an initialcash balance 600A, a credit limit 602A, an initial waived margin balance604A, and a maximum total margin balance 606A. Current balances 160 mayinclude, for example, a current cash balance 600B, an available creditbalance 602B, an available waived margin balance 604B, an availabletotal margin balance 606B, an unrealized profits/losses balance 608, aguaranteed profits balance 610, and a used margin balance 612.

The available waived margin balance 604B and the available total marginbalance 606B for a user's trading account 154 are generally available tothe user for placing trading orders 152 which the user may not otherwisehave been able to place based on the user's current cash balance 600Band available credit balance 602B, as discussed in greater detail belowwith reference to FIGS. 5A-5E. The available waived margin balance 604Band the available total margin balance 606B for a particular tradingaccount 154 may partially or even completely overlap.

One or more initial balances and/or limits 158 associated with a newtrading account 154 may be determined by balance management module 136based at least on the type or types of the new trading account 154. Forexample, a particular user may be approved for (1) a “small creditaccount” providing a $500 credit limit 602A and a $1,250 initial waivedmargin balance 604A, and (2) a “hybrid credit/deposit account” providinga $500 credit limit 602A and a $1,250 initial waived margin balance604A, plus an initial cash balance 600A including any deposited amounts,while being denied (3) a “large credit account” providing a $1,000credit limit 602A and a $2,500 initial waived margin balance 604A.

Since the type or types of trading accounts 154 approved for aparticular user may be based on credit information 308 regarding theuser (as discussed above), one or more initial balances and/or limits158 for the user's trading account 154 may be determined based at leastin part on particular credit information 308 regarding the user. Inaddition, one or more initial balances and/or limits 158 associated witha trading account 154 may otherwise be determined based at least in parton particular credit information 308 regarding the relevant user. Forexample, in some embodiments, one or more initial balances and/or limits158 associated with a trading account 154 may not be specificallydefined by the type of the trading account 154. In such embodiments,balance management module 136 may determine any initial balances and/orlimits 158 associated with a new trading account 154.

In some embodiments, the initial waived margin balance 604A for atrading account 154 (at least initially) is proportional to the creditlimit 602A determined for the trading account 154. For example, in oneembodiment, the initial waived margin balance 604A for each tradingaccount 154 is equal to 2.5 times the credit limit 602A determined forthat trading account 154. To illustrate, in such an embodiment, a userprovided with a $500 credit limit 602A would be provided with a $1,250(in other words, 2.5*$500) initial waived margin balance 604A.

Balance management module 136 may determine a maximum total marginbalance 606A for a new trading account 154 based at least in part onparticular credit information 308 regarding the user. In one embodiment,the maximum total margin balance 606A for a new trading account 154 maybe determined independently of the initial cash balance 600A, the creditlimit 602A and the initial waived margin balance 604A for the newtrading account 154. For example, suppose balance management module 136approves a large credit account for each of two users, each large creditaccount providing the respective user a credit limit 602A of $1,000 andan initial waived margin balance 604A of $2,500. Balance managementmodule 136 may provide one of the two users a higher maximum totalmargin balance 606A than the other based at least in part on creditinformation 308 regarding the users.

In this manner, trading platform 20 may determine the amount of variousinitial balances and/or limits 158 based on the perceived credit risk ofthat user (according to various credit information 308 regarding theuser), which may reduce the amount of uncollected debts owed by users totrading platform 20.

In addition, balance management module 136 may manage, such as byupdating or adjusting, one or more current balances 160 for tradingaccounts 154 over time based at least on the initial balances and/orlimits 158 for such trading accounts 154, any trading activity performedusing the trading account 154 and/or any deposits or withdrawals to orfrom the trading account 154.

For example, if a trade is executed for a user—in other words, if theuser places a trading order 152 and the trading order 152 is matched byanother trading order 152—balance management module 136 may increase theused margin balance 612 by an amount equal to (or at least based on) therisk value 332 for the trading order 152, thus reducing the availablewaived margin balance 604B and the available total margin balance 606Bfor the trading order 152 (based on equations 3 and 4 shown in FIG. 5A,for example), as discussed below with reference to product managementmodule 138.

Risk Management

In order to understand various aspects of the risk management functionsprovided by trading platform 20, it is helpful to understand some basicconcepts and terminology regarding betting products 150 and tradingorder 152. An example betting product 150, as well as example tradingorders 152 to buy and to sell such betting product 150, are providedbelow in the context of a spread betting system.

Suppose a betting product 150 which comprises a spread bet regarding thenumber of runs England will score in their first innings in the FirstTest between England and India in cricket. Further suppose that thequote is 220-240 runs, which indicates that England is expected to scorebetween 220 and 240 runs. A user who believes that England will score,say, 400 runs may make a request to place a trading order 152 to buy thebetting product 150 at the higher quote, or “price,” of 240 runs. Theuser (who may be referred to as the “buyer”) will specify a unit stakefor the trading order 152, which in this case represents the amount perrun that the user wishes to bet.

Suppose, for example, the buyer requests a trading order 152 to buy thebetting product 150 for £5/run at the quote of 240 runs, and the tradingorder 152 is placed and matched (i.e., the trade is executed). The unitstake of the trading order 152 is £5/run and the quote, or “price,” is240 runs. For every run above 240 that England scores, the buyer wins£5. However, for every run below 240 that England scores, the buyerloses £5. Thus, if England scores 300 runs, the buyer wins (300 runs-240runs)*(£5/run), which equals £300. However, if England scores just 170runs, the buyer loses (240 runs-170 runs)*(£5/run), which equals £350.

On the other hand, a user (who may be referred to as the “seller”) whobelieves that England will score, say, 150 runs may make a request toplace a trading order 152 to sell the betting product 150 at the lowerquote, or price, of 220. The seller will specify a unit stake for thetrading order 152, which again represents the amount per run that theuser wishes to bet.

Suppose, for example, the seller requests a trading order 152 to sellthe betting product 150 for £3/run at the quote of 220 runs, and thetrading order 152 is placed and matched (i.e., the trade is executed).The unit stake of the trading order 152 is £3/run and the quote, or“price,” is 220 runs. For every run below 220 that England scores, theseller wins £3. However, for every run above 220 that England scores,the seller loses £3. Thus, if England scores 150 runs, the seller wins(220 runs-150 runs)*(£3/run), which equals £210. However, if Englandscores 400 runs, the seller loses (400 runs-220 runs)*(£3/run), whichequals £540.

It should be understood that although the example betting product 150and trading orders 152 discussed above relate to a spread bettingsystem, some or all of the concepts discussed herein may similarly applyto any other types of betting products 150 and trading orders 152, andin the context of any other type of betting system, without departingfrom the scope of this disclosure.

Generally, each trading order 152 that a user requests to be placed ontrading platform 20 is based on at least one betting product 150, suchas described above regarding the example betting product 150 and tradingorders 152 to buy and sell the betting product 150. Each betting product150 has a risk factor 330 (see FIG. 2) which generally represents theactual or estimated maximum number of “ticks” for which the user may beliable on a particular betting product 150. A “tick” may represent thetype of scoring unit upon which a betting product 150 is based, such as,for example, a run (such as in cricket or baseball, for example), goal(such as in soccer or hockey, for example), point (such as in Americanfootball, basketball, or rugby, for example), minute (such as for abetting product 150 regarding the time of the first goal in a soccermatch, for example), shirt number (such as for a betting product 150regarding the total of the shirts numbers of the goal scorers in asoccer match, for example), or stroke (such as a golf stroke, forexample). It should be understood that a tick may represent any numberor fraction of such scoring units. For example, in a betting product 150regarding the score of an American football match, each tick mayrepresent one point, and in a betting products 150 regarding the scoreof a soccer match, each tick may represent 0.1 goals. In the examplesused throughout the remainder of this disclosure, it is assumed thateach tick represents one scoring unit.

In some embodiments, the value of the risk factor 330 of a bettingproduct 150 represents the actual or estimated maximum amount that thebuyer or seller of the betting product 150 could lose by wagering oneunit of currency (such as $1/point or £1/goal, for example) on thebetting product 150. For example, suppose in the example discussed aboveit is determined that the risk factor 330 for buying or selling theexample betting product 150 is equal to 200 runs. The actual orestimated maximum amount that a buyer or seller of the betting product150 could lose on a stake of £1/run would thus be £200.

In addition, each trading order 152 has a risk value 332 (see FIG. 2)that generally represents the total actual or an estimated maximumamount that a user could lose on the trading order 152, based at leaston the unit stake of the trading order 152 and the risk factor 330 ofthe underlying betting product 150. As discussed above, the unit stakeof a trading order 152 refers to the size of the trading order 152, suchas measured in units, shares, pounds, dollars, or any other type ofcurrency, for example. Risk factors 330 and risk values 332 may bedetermined by product management module 138 and order management module140, respectively, as discussed in greater detail below.

In a particular embodiment, the risk value 332 for a trading order 152is determined by multiplying the risk factor 330 for the betting product150 underlying the trading order 152 by the size, or unit stake, of thetrading order 152. Thus, in the example discussed above, the risk value332 for the buyer's trading order 152 (risk factor=200 runs, unitstake=£5/run) would be (200 runs)*(£5/run), which equals £1000. The riskvalue 332 for the seller's trading order 152 (risk factor=280 runs, unitstake=£3/run) would be (200 runs)*(£3/run), which equals £600.

Trading platform 20 determines whether to place each requested tradingorder 152 for a particular user (in other words, whether to approve theuser's request to place each trading order 152) based at least in parton one or more equations or algorithms involving the risk value 332 ofthat trading order 152 and one or more current balances 160 (orcombinations thereof) of the user's trading account 154, as discussed ingreater detail below with reference to order management module 140 andFIGS. 5A-5E. Such equations or algorithms may include one or morecomparisons between the risk value 332 of the trading order 152 and oneor more current balances 160 of the trading account 154.

As discussed above, one or more current balances 160 associated with atrading account 154 may be based at least in part on one or more initialbalances and/or limits 158 for that trading account 154, which may bebased at least in part on credit information 308 received from one ormore credit verification entities 106 regarding the user. Thus, in someembodiments, there is a relationship between the credit information 308regarding a particular user, the risk value 332 determined for a tradingorder 152 requested by that user, and whether or not that trading order152 will be placed on trading platform 20.

In addition, relationships may exist between the risk values 332determined for trading orders 152 placed for a particular user and themanagement over time of one or more current balances 160 associated withthe user's trading account 154. For example, as discussed above, if auser's trading order 152 is matched, or executed, the used marginbalance 612 may be increased, and thus the available waived marginbalance 604B and available total margin balance 606B reduced, by anamount equal to (or at least based on) the risk value 332 associatedwith the trading order 152.

Balance management module 136 may reduce and/or increase one or morecurrent balances 160 associated with the user's trading account 154 in aparticular order. For example, in one embodiment, when a user's tradingorder 152 is executed, the user's available waived margin balance 604Band available total margin balance 606B are reduced by an amount equalto the risk value 332 of the trading order 152. If the user loses aparticular loss amount on the executed trading order 152, the lossamount may be subtracted from the user's available cash balance 600B andthe amount of the risk value 332 of the trading order 152 may be addedback to the available waived margin balance 604B and available totalmargin balance 606B. If the user's available cash balance 600B is zero,the loss amount may be instead subtracted from the user's availablecredit balance 602B. However, it should be understood that in otherembodiments, balance management module 136 may reduce and/or increasecurrent balances 160 in any suitable order or according to anypredefined method or approach.

Product management module 138 is generally operable to create and/ormanage various betting products 150 that may be traded by users oftrading platform 20. As discussed above, a betting product 150 mayrepresent a type of bet, such as a sports bet, for example. For example,a betting product 150 may include a bet regarding the winner of afootball match or horse race, a bet regarding the winner of a series ofmatches such as a series of cricket test matches, a bet regarding thefinal standings of a football team for a season, a bet regarding thetotal shirt number of the scorers in an English football match, or a betregarding the number of runs by one team during the first innings of acricket match. In some embodiments, types of betting products 150include, for example, (1) cumulative market, or total number, bettingproducts (such as a bet on the corner kicks in a football match, or abet on batsmen runs in a cricket innings or match, for example), (2)indices betting products (such as a league championship index in which1st place gets 6 points, 2nd place gets 4 points, 3rd place gets 3points, and 4th place gets 1 point, for example), (3) match bets, orsupremacy betting products (such as a bet on the final scoredifferential in a football match, for example) and/or (4) time marketbetting products (such as a bet on the minute of the first goal in asoccer match, for example).

Several terms should be introduced at this point. First, the term“make-up” refers to the final result of an event (such as a game ormatch) or group of events. The terms “maximum make-up” and “minimummake-up” refer respectively to the largest and smallest possible result,or make-up, of the event or group of events. The term “so-far” refers tothe total result at a particular point in time (such as the score of afootball match at a point during the match, for example). The term“maximum possible loss” or “maximum potential loss” refers to themaximum amount that may be lost on a bet, such as the maximum amountthat may be lost per share or unit of currency (such as $1 or £1, forexample) wagered on a particular betting product 150 or the maximumamount that may be lost on a particular trading order 152, for example.

In some embodiments, product management module 138 is operable to createany number of betting products 150, including defining the relevantparameters of the betting product 150 (such as, for example, the type,the sport, event, player, horse, score, point spread and/or finalstandings position). As discussed above regarding the example bettingproduct 150 on the number of runs scored by England in the cricketmatch, a trading order 152 may define the user's position on theunderlying betting product 150 (buyer or seller, for example), the quoteor “price” for the betting product 150, and the unit stake to be wageredon the betting product 150. In addition, product management module 138may assign to each betting product 150 a suggested or estimated initialquote or “price.” For example, in the example discussed above, productmanagement module 138 may assign the betting product 150 an initialquote of 225-245 runs. In particular embodiments, product managementmodule 138 is operable to base such quotes or prices on the quotes orprices determined for such betting products 150 by a known bettingentity, such as a bookmaker, for example.

In addition, as mentioned above, product management module 138determines and/or manages a risk factor 330 for each betting product 150(or a risk factor 330 for each of the buyer and the seller of eachbetting product 150) representing an actual or estimated maximum amountof liability to which a user may be exposed by establishing a position(such as a buy or sell position) in that betting product 150.

As discussed above, in some embodiments, the risk factor 330 representsthe actual or estimated maximum number of “ticks,” or scoring units, forwhich the user may be liable on a particular betting product 150. Inaddition, as discussed above, the value of the risk factor 330 of abetting product 150 may represent the actual or estimated maximum amountthat the buyer or seller of the betting product 150 could lose per unitof currency (such as $1/point or £1/goal, for example) wagered on thebetting product 150. For example, if the risk factor 330 of a bettingproduct 150 was equal to 3 goals, the actual or estimated maximum amountthat a buyer of the betting product 150 could lose on a stake of £1/goalwould be £3. Thus, as discussed below in greater detail, in someembodiments, the total liability for the buyer or seller is equal to therisk factor 330 of the betting product 150 multiplied by the monetaryamount, or “unit stake,” that the buyer or seller wagers on the bettingproduct 150.

Product management module 138 may determine risk factors 330 forparticular betting products 150 based at least on the actual maximumtick liability 352 associated with the betting product 150 and/or anestimated maximum tick liability 354 associated with the betting product150. In some situations, such as for particular types of bettingproducts 150, the actual maximum tick liability 352 is infinite orundefined. For example, for supremacy betting products 150, there is nolimit to the final score differential for either team, and thus theactual maximum tick liability 352 for both the buyer and seller isinfinite.

In some embodiments, product management module 138 may also determine astop-loss tick liability 356 for particular betting products 150 for usewith stop-loss trading orders 152 or stop-loss trading accounts 154, asdiscussed below.

In some embodiments, one or both of the actual maximum tick liability352 and the estimated maximum tick liability 354 for particular bettingproducts 150 are determined by product management module 138. In otherembodiments, one or both of the actual maximum tick liability 352 andthe estimated maximum tick liability 354 for particular betting products150 may be determined by another entity (such as a bookmaker, forexample) and supplied to product management module 138.

In some situations, product management module 138 may determine riskfactors 330 for betting products 150 by selecting the lower of theactual maximum tick liability 352 and the estimated maximum tickliability 354 for the particular betting product 150.

The estimated maximum tick liability 354 for a betting product 150 maybe based at least in part on statistical data regarding the event orevents upon which the betting product 150 is based. For example, supposea cumulative market betting product 150 representing a bet on the numberof points scored in an American football game. The estimated maximumtick liability 354 for the betting product 150 may be determined basedat least in part on the range of scores for a particular historicalsample games, such as all American football games played over theprevious five years, or all games over the previous three years betweenthe two teams involved in the game associated with the betting product150, for example. For example, in one embodiment the estimated maximumtick liability 354 may be based at least in part on a range of scores inwhich 95% of the historical sample of games fell within. For example,supposing that the total score in 95% of all American football gamesplayed over the previous five years fell within a 70 point spread (forexample, between 10 and 80 total points), product management module 138may determine that the estimated maximum tick liability 354 for buyingor selling a betting product 150 on an American football game is half ofthat 70 point spread, or 35 points.

In this manner, trading platform 20 may be able to estimate the maximumpossible tick liability (i.e., the estimated maximum tick liability 354)for buyers and sellers of various betting products 150, which may beused by balance management module 136 in managing one or more currentbalances 160 associated with users' trading accounts 154 over time, asdiscussed in greater detail below. In some embodiments, the estimatedmaximum tick liability 354 for the buyer and the seller remains constantfor the duration of the betting product 150. Thus, in such embodiments,even as the so-far of the event or events underlying a betting product150 changes, the estimated maximum tick liability 354 for the bettingproduct 150 remains constant, as discussed below. In alternativeembodiments, the estimated maximum tick liability 354 for the buyerand/or the seller of a betting product 150 may change over time. Forexample, in one embodiment, the estimated maximum tick liability 354 forthe buyer and/or the seller of a betting product 150 may be updatedduring the underlying event based on the so-far of the event.

As mentioned above, in some embodiments, product management module 138may determine one or more risk factors 330 for a betting product 150 byselecting the lower of the actual maximum tick liability 352 and theestimated maximum tick liability 354 for the betting product 150.

To illustrate, suppose that the quote on the American football bettingproduct 150 is 30-33 points, and that the estimated maximum tickliability 354 for buying or selling the betting product 150 is 35points. Further suppose that a first user (seller) makes a request toplace a trading order 152 to sell the betting product 150 at the sellquote of 30 points, and a second user (buyer) makes a request to place atrading order 152 to buy the betting product 150 at the buy quote of 33points.

For the buyer, the actual maximum tick liability 352 is equal to the buyquote, or price, (33 points) minus the initial minimum make-up (0point), or 33 points, which represents the buyer's tick liability if thefinal score (make-up) is zero-zero. As discussed above, the estimatedmaximum tick liability 354 for the buyer is 35 points. Thus, the riskfactor 330 for the buyer at the time the trade is executed is determinedto be 33 points (the lower of 33 points and 35 points).

For the seller, the actual maximum tick liability 352 is infinite, sincethe total number of points which could be scored in the football game istheoretically infinite. As discussed above, the estimated maximum tickliability 354 for the seller is 35 points. Thus, the risk factor 330 forthe seller at the time the trade is executed is determined to be 35points (the lower of infinity and 35 points).

In some embodiments, each type of betting product 150 may have a set ofrules defining how the risk factor 330 for each betting product 150 ofthat type is determined. Example rules for four types of bettingproducts 150 mentioned above—namely, (1) cumulative market bettingproducts, (2) indices betting products, (3) match bets, or supremacybetting products, and (4) time market betting products—are provided asfollows.

(1) Cumulative market betting products. Cumulative market bettingproducts 150 include markets that have a minimum make-up (typicallyzero), and the so-fars can only increase. For example, cumulativemarkets include the total of shirts numbers worn by goal-scorers by oneor both teams in a football match, or the number of batsmen runs for oneteam in a cricket innings or match. The example betting product 150discussed above regarding the total number of points scored in anAmerican football game is a particular example of a cumulative marketbetting products 150.

As discussed above regarding the example American football bettingproduct 150, the risk factor 330 for a buyer will be the lesser of theactual maximum tick liability 352 and the estimated maximum tickliability 354. The actual maximum tick liability 352 for the buyer isequal to the buy quote, or “price,” minus the actual minimum make-up. Inthis situation, the actual minimum make-up is equivalent to the currentso-far.

The risk factor 330 for a seller will also be the lesser of the actualmaximum tick liability 352 and the estimated maximum tick liability 354.The actual maximum tick liability 352 for the seller is equal to theactual maximum make-up minus the sell quote, or “price.” Since theactual maximum make-up is typically infinite for a cumulative marketbetting product, the actual maximum tick liability 352 for the sellerwill typically be infinite. Thus, the risk factor 330 for the sellerwill be equal to the estimated maximum tick liability 354 for theseller.

The scenario discussed above regarding the example American footballbetting product 150 illustrates an example of determining initial riskfactors 330 for both a buyer and a seller of a cumulative market bettingproduct 150. As discussed above, for the buyer, the actual maximum tickliability 352 was 35 points, the estimated maximum tick liability 354was 33 points, and the risk factor 330 was determined to be 33 points(the lower of 35 points and 33 points). For the seller, the actualmaximum tick liability 352 was infinite, the estimated maximum tickliability 354 was 35 points, and the risk factor 330 was determined tobe 35 points (the lower of infinity and 35 points).

Further suppose that at half-time, the score of the football game is21-7, for a total of 28 points scored. The actual minimum make-up (equalin this situation to the so-far), which began at 0 points, is now 28points. As discussed above, the actual maximum tick liability 352 forthe buyer is equal to the buy quote minus the actual minimum make-up,which is now equal to 33 points minus 28 points, or 5 points. Assumingan embodiment in which the estimated maximum tick liability 354 for thebetting product 150 remains constant throughout the duration of thebetting product 150 (as discussed above), the estimated maximum tickliability 354 for the buyer remains constant at 33 points. Thus, sincethe risk factor 330 for the buyer is equal to the lower of the actualmaximum tick liability 352 and the estimated maximum tick liability 354,the risk factor 330 for the buyer may be updated from 33 points (priorto the game) to 5 points (at half-time).

For the seller, the actual maximum tick liability 352 is equal to theactual maximum make-up minus the sell quote, which is stilltheoretically infinite. The estimated maximum tick liability 354 for theseller may increase from 33 points since it is likely (based on the factthat 28 points were scored in the first half) that more than 33 pointswill be scored in the game. For example, suppose the estimated maximumtick liability 354 for the seller increases from 33 points to 52 points.Thus, the risk factor 330 for the seller may be updated from 33 points(prior to the game) to 52 points (at half-time).

Thus, it can be seen that the estimated maximum tick liability 354 forthe seller of a betting product 150 may change during the event orevents underlying the betting product 150. Similarly, in somesituations, the estimated maximum tick liability 354 for the buyer of abetting product 150 may change during the event or events underlying thebetting product 150.

Thus, as shown in the example discussed above, product management module138 may update the risk factors 330 for buyer and/or sellers of variousbetting products 150 during the lifetime of such betting products 150.For example, product management module 138 may update the risk factors330 of various betting products 150 each time one or more relevantparameters of the risk factors 330 change, such as the actual minimummake-up, the actual maximum make-up, the so-far, the actual maximum tickliability 352 and/or the estimated maximum tick liability 354, forexample. In some embodiments, such updates to risk factors 330 are madeperiodically or substantially in real time, and may be used to updateother parameters, such as the risk values 332 of the associated tradingorders 152, one or more current balances 160 associated with the buyer'sand/or seller's trading accounts 154, and/or the unit stake of one ormore of the buyer's and/or seller's other unmatched trading orders 152on trading platform 20, as discussed in greater detail below withreference to order management module 140, as well as the discussion ofFIG. 10.

(2) Indices betting products. Indices betting products 150 includemarkets in which pre-defined awards are given to teams or playersfinishing in particular positions in the standings. For example, aleague championship index 60/40/30/20/10 is an index in which the leaguechampion is awarded 60 points, 2nd place is awarded 40 points, 3rd placeis awarded 30 points, 4th place is awarded 20 points, and 5th place isawarded 10 points. An indices betting product 150 is typically a betconcerning the final standing of a particular team or player within theleague. Thus, there may be a separate betting product 150 for each teamor player in the league. For such betting products 150, each team orplayer has an initial actual minimum make-up of zero and an initialactual maximum make-up equal to the amount awarded to the champion(thus, for betting products 150 related to the example leaguechampionship index discussed above, the actual maximum make-up is 60points). As the tournament or season progresses, the actual minimummake-up and/or the actual maximum make-up for each team may be differentand may change over time. For example, suppose toward the end of aseason, a team is in a position in which they can finish no worse than4th place (equal to 20 points), but no better than 2nd place (equal to40 points). At that point, for a betting product 150 for that team, theactual minimum make-up would be 20 points and the actual maximum make-upwould be 40 points.

The estimated maximum tick liability 354 for buyers and/or sellers ofindices betting products 150 may have any suitable values. For example,for the league championship index betting product 150 discussed above,the estimated maximum tick liability 354 for both buyers and sellers maybe 15 points. Such values for the estimated maximum tick liability 354for the buyer and/or seller may be any value determined by tradingplatform 20 or any other suitable entity, such as a bookmaker, and suchvalues typically fall between the actual minimum make-up and the actualmaximum make-up for the relevant betting product 150.

For buyers, the risk factor 330 of such indices betting product 150 willbe the lesser of the actual maximum tick liability 352 and the estimatedmaximum tick liability 354. The actual maximum tick liability 352 forthe buyer is equal to the buy quote, or “price,” minus the actualminimum make-up.

For sellers, the risk factor 330 will also be the lesser of the actualmaximum tick liability 352 and the estimated maximum tick liability 354.The actual maximum tick liability 352 for the seller is equal to theactual maximum make-up minus the sell quote, or “price.” As discussedabove, the estimated maximum tick liability 354 for the seller may bethe same as the estimated maximum tick liability 354 for the buyer.

For example, suppose a trading order 152 based on an index marketbetting product 150 for the final position of the team in the leaguechampionship standings, as discussed above. Suppose a quote, or “price,”for the betting product 150 is 24-26 points. For a buyer of the bettingproduct 150, the initial risk factor 330 will be the lesser of theinitial actual maximum tick liability 352 and the estimated maximum tickliability 354, as discussed above. The initial actual maximum tickliability 352 for the buyer is equal to the buy quote, or “price,” minusthe initial minimum make-up, which is equal to 26 points minus 0 points,or 26 points, while the estimated maximum tick liability 354 is 15points. Thus, the initial risk factor 330 for the buyer is determined tobe 15 points.

For the seller, the initial risk factor 330 will also be the lesser ofthe actual maximum tick liability 352 and the estimated maximum tickliability 354, as discussed above. The actual maximum tick liability 352for the seller is equal to the initial actual maximum make-up minus thesell quote, or “price,” which is equal to 60 points minus 24 points, or34 points, while the estimated maximum tick liability 354 is 15 points.Thus, the initial risk factor 330 for the seller is also determined tobe 15 points.

Further suppose that toward the end of the season, the team is in aposition in which they can finish no worse than 4th place (equal to 20points), but no better than 2nd place (equal to 40 points), as discussedabove. At that point, for the betting product 150 traded between thebuyer and seller, the actual minimum make-up would now be 20 points andthe actual maximum make-up would now be 40 points.

For the buyer, the actual maximum tick liability 352 is equal to the buyquote, or “price,” minus the actual minimum make-up (now 20 points), asdiscussed above, which is now equal to 26 points minus 20 points, or 6points. The estimated maximum tick liability 354 for the buyer mayremain constant at 15 points, as discussed above. Since the risk factor330 for the buyer is the lesser of the actual maximum tick liability 352(6 points) and the estimated maximum tick liability 354 (15 points), therisk factor 330 for the buyer may be updated to become 6 points.

For the seller, the actual maximum tick liability 352 is the actualmaximum make-up (now 40 points) minus the sell quote, or “price,” asdiscussed above, which is now equal to 40 points minus 26 points, or 14points. The estimated maximum tick liability 354 for the seller mayremain constant at 15 points, as discussed above. Since the risk factor330 for the seller is the lesser of the actual maximum tick liability352 (14 points) and the estimated maximum tick liability 354 (15points), the risk factor 330 for the seller may be updated to become 14points.

As discussed above, such updates to the buyer's and/or seller's riskfactors 330 may be made periodically or substantially in real time, andmay be used to update other parameters, such as the risk values 332 ofthe associated trading orders 152, one or more current balances 160associated with the buyer's and/or seller's trading accounts 154, and/orthe unit stake of one or more of the buyer's and/or seller's otherunmatched trading orders 152 on trading platform 20, as discussed ingreater detail below with reference to order management module 140, aswell as the discussion of FIG. 10.

(3) Match bets and supremacy betting products. Match bets and supremacybetting products 150 include bets on the final score of a sportingevent, such as a bet on the goal differential in an English footballmatch, for example. Some match or supremacy betting products 150 do nothave an actual maximum or minimum make-up. For example, a supremacy betfor an English football match does not have either an actual maximum orminimum make-up, since either team may win by any amount of goals. Suchbetting products 150 may be called open-ended match or supremacy bettingproduct 150. For match bets and supremacies, the so-far does not affectthe buyer's or seller's risk factor 330, since the so-far does notaffect the actual maximum tick liability 352.

For open-ended match or supremacy betting products 150, the risk factor330 for both the buyer and seller may be equal to the estimated maximumtick liability 354 for the buyer and seller, respectively, since theactual maximum tick liability 352 for both the buyer and seller isinfinite or undefined. The estimated maximum tick liability 354 for thebuyer and seller may be any value determined by trading platform 20 orany other suitable entity, such as a bookmaker, for example. Inaddition, as discussed above, the estimated maximum tick liability 354for the seller may be the same as the estimated maximum tick liability354 for the buyer. For example, in one embodiment, an estimated maximumtick liability 354 of 3 goals is generally used for both buyers andsellers of English Premier League football match or supremacy bettingproducts 150. Thus, the risk factor 330 for both buyers and sellers ofsuch betting products 150 will also be 3 goals.

Other match or supremacy betting products 150 may have an actual minimummake-up and/or an actual maximum make-up. For example, a horse racematch bet may have an actual minimum make-up of negative 12 positionsand an actual maximum make-up of positive 12 positions. Such bettingproducts 150 may be called constrained match or supremacy bettingproducts 150. For buyers of such constrained match or supremacy bettingproducts 150, the risk factor 330 may be equal to the lesser of theactual maximum tick liability 352 and the estimated maximum tickliability 354. The actual maximum tick liability 352 for the buyer isequal to the buy quote, or “price,” minus the actual minimum make-up.For sellers of such constrained match or supremacy betting products 150,the risk factor 330 will also be the lesser of the actual maximum tickliability 352 and the estimated maximum tick liability 354. The actualmaximum tick liability 352 per share for the seller is equal to theactual maximum make-up minus the sell quote, or “price.” The estimatedmaximum tick liability 354 for the seller may be the same as theestimated maximum tick liability 354 for the buyer.

In some situations, no estimated maximum tick liability 354 may beprovided for a constrained match or supremacy betting product 150. Insuch situations, the risk factor 330 for the buyer and seller will beequal to the actual maximum tick liability 352 for the buyer and seller,respectively. For example, suppose a horse race betting product 150having an actual minimum make-up of negative 12 positions, an actualmaximum make-up of positive 12 positions, and no estimated maximum tickliability 354. Suppose the betting product 150 was traded at a spread of2.3-2.5 positions. The risk factor 330 for the buyer will be equal tothe actual maximum tick liability 352 for the buyer, which, as discussedabove, is equal to the buy quote, or “price,” minus the actual minimummake-up, which is equal to 2.3 positions minus (−12 positions), or 14.3positions. The risk factor 330 for the seller will be equal to theactual maximum tick liability 352 for the seller, which, as discussedabove, is equal to the maximum make-up minus the sell quote, or “price,”which is equal to 12 positions minus 2.5 positions, or 9.5 positions. Asdiscussed above, the so-far for such a betting product 150 does notaffect the buyer's or seller's risk factor 330, since the so-far doesnot affect the actual maximum tick liability 352 for the buyer or seller(in other words, a horse which is in 4th position after ½ of the racemay finish the race in any position).

(4) Time market betting products. Time market betting products 150include bets regarding the timing of particular events within a sportingmatch or season, for example. Such betting products 150 generally haveboth an actual minimum make-up and an actual maximum make-up. Forexample, suppose a time market betting product 150 comprising a bet onthe time of the minute of the first goal in a football match. Such abetting product 150 may have an actual minimum make-up of 1 minute (ifthe first goal is scored in the first minute) and an actual maximummake-up of 90 minutes (if the first goal is scored in the 90th minute orbeyond, or if no goals are scored).

For buyers, the risk factor 330 will be the lesser of the actual maximumtick liability 352 and the estimated maximum tick liability 354. Theactual maximum tick liability 352 for the buyer is equal to the buyquote, or “price,” minus the actual minimum make-up. In this situation,the actual minimum make-up is equivalent to the current so-far. Forsellers, the risk factor 330 will also be the lesser of the actualmaximum tick liability 352 and the estimated maximum tick liability 354.The actual maximum tick liability 352 for the seller is equal to theactual maximum make-up minus the sell quote, or “price.”

The estimated maximum tick liability 354 for both the buyer and sellermay be any value determined by trading platform 20 or any other suitableentity, such as a bookmaker, and typically has a value between theactual minimum make-up and the actual maximum make-up. For example, inthe example discussed above (the bet on the time of the minute of thefirst goal in a football match), the estimated maximum tick liability354 for both the buyer and the seller may be 45 minutes.

For example, suppose a trading order 152 based on a time market bettingproduct 150 for the minute of the first goal in a football match istraded at a quote of 35-38 minutes. Suppose the estimated maximum tickliability 354 both buyers and sellers of this betting product 150 is 45minutes. For the buyer, the initial risk factor 330 will be equal to thelesser of the initial actual maximum tick liability 352 and theestimated maximum tick liability 354, as discussed above. The initialactual maximum tick liability 352 for the buyer is equal to the buyquote, or “price,” minus the initial actual minimum make-up, which isequal to 38 minutes minus 1 minute, or 37 minutes, while the estimatedmaximum tick liability 354 is 45 minutes. Thus, the initial risk factor330 for the buyer is determined to be 37 minutes.

For the seller, the initial risk factor 330 will also be the lesser ofthe actual maximum tick liability 352 and the estimated maximum tickliability 354, as discussed above. The actual maximum tick liability 352for the seller is equal to the initial maximum make-up minus the sellquote, or “price,” which is equal to 90 minutes minus 35 minutes, or 55minutes, while the estimated maximum tick liability 354 is 45 minutes.Thus, the initial risk factor 330 for the seller is determined to be 45minutes.

During the football match, the actual minimum make-up and the actualmaximum make-up change over time (at least before the first goal isscored). In particular, the current actual minimum make-up tracks thecurrent minute of the game, while the current actual maximum make-upequals the initial actual maximum make-up (90 minutes) minus the currentminute of the game. Thus, for example, in the 18th minute of the game(assuming the first goal has not been scored), the current actualminimum make-up is 18 minutes, and the current actual maximum make-up is90 minutes.

The risk factors 330 for the buyer and seller may be calculated andupdated as the actual minimum and maximum make-ups are updated duringthe match. For example, in the 18th minute, the actual maximum tickliability 352 for the buyer is equal to the buy quote, or “price,” minusthe current actual minimum make-up, which is equal to 38 minutes minus18 minutes, or 20 minutes. Since this value (20 minutes) is less thanthe estimated maximum tick liability 354 for the buyer (45 minutes), thecurrent risk factor 330 for the buyer would be 20 minutes. For theseller, the actual maximum tick liability 352 would be equal to thecurrent actual maximum make-up minus the sell quote, or “price,” whichis equal to 72 minutes minus 35 minutes, or 37 minutes. Since this value(37 minutes) is less than the estimated maximum tick liability 354 forthe seller (45 minutes), the current risk factor 330 for the sellerwould be 34 minutes.

As discussed above, such updates to the buyer's and/or seller's riskfactors 330 may be made periodically or substantially in real time, andmay be used to update other parameters, such as the risk values 332 ofthe associated trading orders 152, one or more current balances 160associated with the buyer's and/or seller's trading accounts 154, and/orthe unit stake of one or more of the buyer's and/or seller's otherunmatched trading orders 152 on trading platform 20, as discussed ingreater detail below with reference to order management module 140, aswell as the discussion of FIG. 10.

In some embodiments, more than one estimated maximum tick liability 354may be determined for buyers and/or sellers of particular bettingproducts 150. For example, in one embodiment, a low-risk estimatedmaximum tick liability 354 and a high-risk estimated maximum tickliability 354 are determined for buyers and sellers of each bettingproduct 150. The low-risk estimated maximum tick liability 354 may beused for buyers and/or sellers who are determined by one or morecriteria to be relatively low-risk users, whereas the high-riskestimated maximum tick liability 354 may be used for buyers and/orsellers who are determined by one or more criteria to be relativelyhigh-risk users. Generally, the low-risk estimated maximum tickliability 354 for a particular betting product 150 is equal to or lowerthan the high-risk estimated maximum tick liability 354 for the samebetting product 150. As a result, for some such betting products 150,the amount required for a user identified as a low-risk user to tradethe betting product 150 may be less then the amount required for a useridentified as a high-risk user to trade the same betting product 150(assuming the quote, or “price,” and unit stake wagered on the bettingproduct 150 are the same for the users). This may allow low-risk usersto generally make more trades than similarly-funded high-risk users.

Order management module 140 is generally operable to receive tradingorders 152 from users and to manage such trading orders 152 over time.Users having trading accounts 154 with trading platform 20 may trade(such as by buying and selling) various betting products 150 with eachother using trading platform 20 via communications network 100. In orderto trade a betting product 150, a user requests that a trading order 152regarding the betting product 150 be placed on trading platform 20, suchas by using browser application 116 to select the betting product 150and set a quote, or “price,” and unit stake wagered on the bettingproduct 150 desired to be traded. Order management module 140 receivesthe user's request to place the trading order 152 and determines whetherto approve the request based on one or more various factors. Ordermanagement module 140 may then place the trading order 152 on tradingplatform 20 if the request is approved.

In some embodiments, order management module 140 may determine whetherto approve a user's request to place a trading order 152 to trade aparticular betting product 150 based at least in part on (1) one or morecurrent balances 160 (or combinations thereof) of the user's tradingaccount 154 and (2) the risk value 332 determined for the requestedtrading order 152. The risk value 332 for each requested trading order152 may represent the total actual or estimated likely maximum loss thatthe party requesting the trading order 152 may experience if the tradeis executed.

As mentioned above, order management module 140 determines the riskvalue 332 for each requested trading order 152 based at least in part onthe risk factor 330 determined by product management module 138 for theone or more underlying betting products 150. In some embodiments, therisk value 332 for each trading order 152 is generally determined bymultiplying the risk factor 330 determined for the position of therequesting user (buy or sell) on the underlying betting product 150 bythe unit stake wagered on the betting product 150, as defined by therequested trading order 152. The unit stake wagered on a betting product150 may be represented in terms of monetary amount per appropriate tickor scoring unit. Thus, examples of the unit stake on various bettingproducts 150 include $10/point, £13/minute, and ¥50/goal.

To illustrate an example of determining such risk values 332, recallfrom above the cumulative market betting product 150 representing a beton the total number of points scored in an American football game.Suppose product management module 138 assigns an estimated maximum tickliability 354 of 80 points to this betting product 150, as discussedabove. Further suppose that a first user (the buyer) makes a request toplace a first trading order 152 to buy this betting product 150, such asfor $10/point (the unit stake), at a spread quote of 30-33 points, and asecond user (the seller) makes a request to place a second trading order152 to sell this betting product 150, such as for $15/point (the unitstake), at the same spread quote of 30-33 points.

For the buyer, the risk factor 330 will be the lesser of the actualmaximum tick liability 352 and the estimated maximum tick liability 354.As discussed above, the actual maximum tick liability 352 is equal tothe buy quote, or “price” (33 points) minus the actual minimum make-up(0 points), or 33 points, as discussed above. The estimated maximum tickliability 354 for the buyer is equal to 35 points, as discussed above.Thus, the risk factor 330 for the buyer is 33 points.

For the seller, the risk factor 330 will also be the lesser of theactual maximum tick liability 352 and the estimated maximum tickliability 354. As discussed above, the actual maximum tick liability 352is equal to the actual minimum make-up minus the sell quote, or “price,”which result is infinite, as discussed above. The estimated maximum tickliability 354 for the seller is also equal to 35 points, as discussedabove. Thus, the risk factor 330 for the seller is 35 points.

Order management module 140 may then determine the risk value 332 foreach of the buyer and the seller by multiplying the risk factor 330determined for the buyer and the seller, respectively, by the unit stakewagered on the betting product 150, as defined by each requested tradingorder 152. Thus, order management module 140 would determine the riskvalue 332 for the buyer to be $330 (in other words, 33 points*$10/point)and the risk value 332 for the seller to be $525 (in other words, 35points*$15/point). Thus, as determined by order management module 140,the likely maximum total loss for the buyer is $330 and the likelymaximum total loss for the seller is $525.

In addition, order management module 140 may update the risk value 332of each trading product 152 during the lifetime of the respectivetrading product 152. For example, order management module 140 may updatethe risk value 332 of matched and/or unmatched trading products 152 eachtime one or more relevant parameters of the risk factor 330 of theunderlying betting product 150 changes, such as the actual minimummake-up, the actual maximum make-up, the so-far, the actual maximum tickliability 352 and/or the estimated maximum tick liability 354, forexample. In some embodiments, such updates to the risk values 332 aremade periodically or substantially in real time, and may be used toupdate other parameters, such as one or more current balances 160associated with the buyer's and/or seller's trading accounts 154, and/orthe unit stake of one or more of the buyer's and/or seller's otherunmatched trading orders 152 on trading platform 20, as discussed ingreater detail below with reference to order management module 140, aswell as the discussion of FIG. 10.

To determine whether to approve a user's request to place a tradingorder 152 to buy or sell a particular betting product 150, ordermanagement module 140 may use any suitable methodology, which mayinclude various equations or algorithms, such as described below withreference to FIGS. 5A through 5E, for example. In some embodiments, suchas described below with reference to FIGS. 5A through 5E, suchmethodology may be based at least on the risk value 332 determined forthe requested trading order 152 and one or more initial balances 158and/or current balances 160 associated with the relevant trading account154. For example, the approval determination may include one or morecomparisons of the risk value 332 of the requested trading order 152with one or more initial balances 158, current balances 160 and/orcombinations of such balances 158 and/or 160.

In some embodiments, order management module 140 may determine an amountavailable for trading 620 in the relevant trading account 154 based atleast on one or more initial balances 158 and/or current balances 160associated with the trading account 154. In one embodiment, the amountavailable for trading 620 in the trading account 154 must be greaterthan or equal to the risk value 332 for the requested trading order 152in order for the requested trading order 152 to be approved to be placedon trading exchange 20.

In addition, order management module 140 may determine whether or not amargin call is appropriate, as well as the amount of such margin call,for a trading account 154 based at least on one or more initial balances158 and/or current balances 160 associated with the trading account 154,such as discussed below with reference to FIG. 5C, for example.

A stop-loss trading account 154 generally allows a user to limit or caphis or her potential liability for trading particular betting products150. In some embodiments, the users potential losses from tradingparticular betting products 150 may be limited, while the user'spotential gains from trading such betting products 150 may be unlimited.In alternative embodiments, the user's potential gains may be limitedalong with the user's potential losses.

With a stop-loss trading account 154, the user's liability for trading aparticular betting product 150 may be limited based at least on thestop-loss tick liability 356 associated with the betting product 150.The stop-loss tick liability 356 for a betting product 150 may definethe maximum tick liability to which a user having a stop-loss tradingaccount 154 may be exposed on the betting product 150. For example,suppose a betting product 150 regarding an American football game has astop-loss tick liability 356 of 75 points. If a user sells this bettingproduct 150 using a stop-loss trading account 154, the user's maximumtick liability will be 75 points. Thus, the seller will not be liablefor any points scored above 75 points. Thus, if the user placed atrading order 152 to sell $10 (unit stake) of this betting product 150,the user's total potential loss on the trading order 152 is capped at$750, regardless of how many points are scored in the game.

Thus, in some embodiments, a user having a stop-loss trading account 154may place particular trading orders 152 for which the user's potentiallosses are limited, but potential gains are (at least theoretically)unlimited. To account for this imbalance, trading exchange 20 may use alarger spread between the buy price and sell price for trading bettingproducts 150 using stop-loss trading accounts 154 than would otherwisebe used. For example, trading exchange 20 may use a five point spreadfor trading betting products 150 using stop-loss trading accounts 154 asopposed to a three point spread for trading betting products 150 usingother types of trading accounts 154 (i.e., non-stop-loss accounts).

As discussed above, the stop-loss tick liability 356 for particularbetting products 150 may be determined by product management module 138.Alternatively, the stop-loss tick liability 356 for particular bettingproducts 150 may be determined by a third party entity and communicatedto product management module 138. The stop-loss tick liability 356 for aparticular betting product 150 may be different than the estimatedmaximum tick liability 352 for that betting product 150. The stop-losstick liability 356 for a betting product 150 is typically greater thanthe estimated maximum tick liability 352 for that betting product 150.For example, for a betting product 150 regarding American football, theestimated maximum tick liability 352 may be 45 points and the stop-losstick liability 356 may be 75 points. However, for particular bettingproducts 150, the stop-loss tick liability 356 may be lower than theestimated maximum tick liability 352.

It should be understood that although stop-loss trading accounts 154 aredescribed above, particular betting products 150 or trading orders 152may be designated as stop-loss betting products 150 or trading orders152, apart from being used along with a stop-loss trading account 154.Thus the stop-loss concept may apply separately or jointly to bettingproducts 150, trading orders 152 and/or trading accounts 154.

Although the concepts regarding determining and utilizing risk factors330 for betting products 150 and risk factors 332 for trading orders 152are discussed with reference to a trading platform 20, it should beunderstood that in various embodiments some or all of such conceptssimilarly apply beyond the context of a trading platform in which users'trading orders are traded or matched. For example, risk factors 330and/or risk values 332 may be used in connection with betting products150 and/or trading orders 152 traded or placed with an online bookmakeror sportsbook. As another example, risk factors 330 and/or risk values332 may be used in connection with betting products 150 and/or tradingorders 152 traded or placed at a physical wagering facility, such as acasino sportsbook, a bookmaker, or an off-track betting (OTB) facility,for example.

Order management module 140 may also manage the trading orders 152placed on trading platform 20. For example, order management module 140may organize trading orders 152 for various users, based on variousbetting products 150, and at various quotes, or “prices.” In someembodiments, order management module 140 stores (or causes storage of)trading orders 152 into one or more queues 144. Trading orders 152 maybe stored in such queues 144 in a predefined manner, such as accordingto a FIFO (first in, first out) basis and/or according to the offeredprice of each trading order 152, for example. Each queue 144 may includetrading orders 152 for a particular position (for example, a buy or sellposition) for a particular betting product 150. In addition, tradingorders 152 for a particular position on a particular betting product150, but offered for at different quotes, or “prices,” may be stored inseparate queues 144.

Executing Trades

Trade management module 142 is generally operable to identify tradingorders 152 which may be matched, and to match such trading orders 152 toexecute trades. Generally, trade management module 142 identifiesmatches between trading orders 152 to buy particular betting products150 and trading orders 152 to sell the same betting products 150. Trademanagement module 142 may identify trading orders 152 to be matched, orin other words, to determine whether to match particular trading orders152, based at least on the relative quotes, or “prices,” defined by thetrading orders 152. For example, in some embodiments or scenarios, trademanagement module 142 may only match buy and sell trading orders 152having the same quote or price. In other scenarios, trade managementmodule 142 may match orders in which the quote or price for the buyorder 152 is greater than or equal to the quote or price for thecorresponding sell order 152. In still other embodiments or scenarios,trade management module 142 may only match orders in which the quote orprice for the buy order 152 is greater than the quote or price for thecorresponding sell order 152 by a predetermined amount or percentage. Inthis manner, trade management module 142 may match trading orders 152 toexecute trades.

In still other embodiments or scenarios, trade management module 142 maymatch orders in which the quote or price for the buy order 152 isgreater than or equal to the quote or price for the corresponding sellorder 152, as well as orders in which the quote or price for the buyorder 152 is lower than, but within a particular price differential of,the quote or price for the corresponding sell order 152.

As discussed above, order management module 140 may store (or cause thestorage of) trading orders 152 in queues in a predefined manner, such asaccording to a FIFO (first in, first out) basis and/or according to theoffered quote or price of each trading order 152. Trade managementmodule 142 may utilize such queues 144 in order to identify anddetermine whether to match particular trading orders 152. In addition,trade management module 142 may partially or fully match particulartrading orders 152, depending on the unit stake of each trading order152 involved in the trade. For example, suppose User A places a tradingorder 152 to sell a particular betting product 150, betting product X,for $10/point (unit stake) at 42 points (quote). Later, User B places atrading order 152 to sell betting product X for $5/point (unit stake) at42 points (quote). Still later, User C places a trading order 152 to buybetting product X for $25/point (unit stake) at 42 points (quote).

Since User A's and User B's trading orders 152 may be stored in a firstqueue 144 in FIFO order, User A's order will be ahead of User B's orderin first queue 144. Thus, trade management module 142 will first match$10/point of the unit stake of User C's buy order with the $10/pointunit stake of User A's sell order to execute a first trade. Trademanagement module 142 will then proceed to the next order in first queue144, namely User B's order, and match $5/point of the unit stake of UserC's buy order with the $5/point unit stake of User B's sell order toexecute a second trade. Order management module 140 may then store theremaining unmatched $10/point unit stake of User C's buy order in asecond queue 144, which may be matched by subsequently requested sellorders for betting product X at (or below) a quote of 42 points.

In some embodiments, trade management module 142 notifies balancemanagement module 136 each time a trade is fully or partially executed(in other words, each time a trading order 152 is fully or partiallymatched with another trading order 152), such that balance managementmodule 136 may update one or more current balances 160 for the tradingaccounts 154 of each involved user. For example, when a trading order152 is fully matched, balance management module 136 may increase theused margin balance 612 and decrease both the available waived marginbalance 604B and the an available total margin balance 606B in both thebuyer's and the seller's trading accounts 154 by an amount equal to therisk value 332 determined for the buyer's and the seller's relativepositions in the trading order 152. When a trading order 152 ispartially matched, balance management module 136 may increase the usedmargin balance 612 and decrease both the available waived margin balance604B and the an available total margin balance 606B in each of thebuyer's and the seller's trading accounts 154 by an amount equal to therisk factor 330 of the underlying betting product 150 for the buyer'sand the seller's relative positions, multiplied by the portion of theunit stake of the trading order 152 which was matched. As discussedabove, in some embodiments, balance management module 136 may reduceand/or increase one or more current balances 160 in the buyer's and/orseller's trading accounts 154 in a particular order. In this mariner,balance management module 136 may manage various current balances 160 ineach trading account 154 over time based on trading activity performedusing such trading accounts 154.

In addition, balance management module 136 may update one or morecurrent balances 160 for each relevant trading account 154 each timeorder management module 140 updates the risk value 332 of a tradingorder 152 placed on trading platform 20. For example, suppose in theexample discussed above in regarding the American football game that 28points have been scored by halftime. Product management module 138 mayupdate the risk factor 330 for the buyer's from 33 points to 5 points,such as described above. As a result, balance management module 136 mayupdate one or more current balances 160 for the buyer which are tied tothe updated risk factor 330, such as the used margin balance 612, theavailable waived margin balance 604B or the available total marginbalance 606B, for example. Such updated balances 160 may affect theamount available for trading 620 in the buyer's trading account 154.

In some embodiments, as balance management module 136 updates one ormore current balances 160 for a particular user's trading account 154,order management module 140 may determine whether each remainingunmatched, or open, trading order 152 placed using that trading account154 is still valid according to the updated current balances 160. Forexample, if balance management module 136 reduces the available waivedmargin balance 604B and the available total margin balance 606B in atrading account 154, which affects the amount available for trading 620in the user's trading account 154, order management module 140 maydetermine whether the updated amount available for trading 620 issufficient to maintain each remaining unmatched trading order 152 madeusing that trading account 154.

For example, order management module 140 may compare the risk value 332of each remaining unmatched trading order 152 with the updated amountavailable for trading 620 in the trading account 154. For each tradingorder 152, if the risk value 332 of that trading order 152 is less thanor equal to the updated amount available for trading 620, the tradingorder 152 is unaffected. However, for each trading order 152 having arisk value 332 greater than the updated amount available for trading620, the unit stake of that trading order 152 may be reduced such thatthe risk value 332 of the trading order 152 is reduced to an amountequal to (or less than) the updated amount available for trading 620.

For example, suppose a user has a trading account 154 having an amountavailable for trading 620 of $10,000 and several open trading orders152, including the following:

-   -   Order A: sell order for $200/point at 15 points; risk factor of        15 points for a risk value of $3,000.    -   Order B: buy order for $200/run at 50 runs; risk factor of 30        runs for a risk value of $6,000.    -   Order C: sell order for $3,000/goal at 4.5 goals; risk factor of        3 goals for a risk value of $9,000.

Suppose that Order A is fully matched, and that balance managementmodule 136 reduces the amount available for trading 620 in tradingaccount 154 by the amount equal to the risk value 332 of Order A($3,000) from $10,000 to $7,000. Order management module 140 may thendetermine whether the updated amount available for trading 620 of $7,000is sufficient to maintain each of the user's remaining unmatched tradingorders 152, namely Order B and Order C. Since the risk value 332 ofOrder B ($6,000) is less than the updated amount available for trading620 of $7,000, Order B remains unaltered. However, since the risk value332 of Order C ($9,000) is greater than the updated amount available fortrading 620 of $7,000, the unit stake of Order C is reduced from$3,000/goal to $2,333.33/goal such that the updated risk value 332 ofOrder C is $7,000 (in other words, 3 goals*$2,333.33/goal).

In some embodiments, order management module 140 may increase the unitstake of trading orders 152 that were previously decreased, such asdescribed above, if the amount available for trading 620 in the relevanttrading account 154 is increased. For example, in the example discussedabove, if the amount available for trading 620 in the user's tradingaccount 154 is subsequently increased above $7,000, the unit stake ofOrder C may be increased accordingly up to the original $3,000/goal.

Third-Party Intermediary

In some embodiments, trade management module 142 is generally operableto allow trading platform 20, or trading engine 114, to act as anintermediary or agent between various users having trading accounts 154with trading platform 20. For example, when trading orders 152 for aparticular betting product 150 are matched (in other words, when a tradeis executed), trade management module 142 may be operable to establishfinancial obligations between trading platform 20 and each user involvedin the executed trade.

In addition, when the underlying event or events upon which theparticular betting product 150 is based transpire, trade managementmodule 142 may execute transactions between trading platform 20 and eachinvolved user based at least on the results of the underlying event orevents. Such transactions may include, for example, transferring fundsor credit between platform account 155 and each involved user.

For example, if User A and User B trade a particular betting product 150and User B is victorious on the underlying bet such that User A owesfunds to User B, trade management module 142 may execute a firsttransaction transferring funds or credit from User A's trading account154 to platform account 155, and a second transaction transferring fundsor credit from platform account 155 to User B's trading account 154. Insome embodiments, trade management module 142 may execute suchtransactions independently such that each transaction does not depend onthe execution of the other.

In this manner, trading platform 20 acts, in some embodiments, as anintermediary for effecting transactions between various users, such asthe example Users A and B. In addition, although trade management module142 creates obligations and executes a separate transaction with eachuser involved in a trade, it may appear to each user involved in thetrade that that user is transacting directly with the other user. Thus,it may be said that trade management module 142 effectuates a “virtual”transaction between the users involved in each trade. The function andoperation of trade management module 142 is described in greater detailbelow with reference to FIGS. 10 and 11.

Trading engine 114 may comprise a central processing unit (CPU)associated with an operating system that executes instructions andmanipulates information in accordance with the operation of tradingplatform 20. The CPU of trading engine 114 maintains and executesinstructions to implement the various features and functionalitiesassociated with core servers 120 and database server 122, such as thefunctionalities provided by the various function modules 126 describedabove. Although the various components of trading engine 114 areillustrated as separate servers and modules, it should be understoodthat any suitable number and combination of servers, modules may, orprocessors be used to perform the various features and functionality oftrading engine 114.

Although trading platform 20 or trading engine 114 may act as anintermediary or agent between various users in some embodiments (such asdiscussed above and in greater detail with reference to FIGS. 10 and11), in other embodiments trading platform 20 allows users to tradedirectly with each other, including establishing financial obligationsdirectly with each other.

FIG. 2 illustrates an example operation of system 10 in accordance withone embodiment of the present invention. Trading platform 20 receives anaccount application 300 for a credit trading account 154 or a tradingaccount 154 comprising a credit component (such as a hybridcredit/deposit account, for example), determines whether to approve thetrading account 154, and opens the trading account 154, all during thesame communication session 148 between a user operating client 104 andtrading platform 20. In addition, trading platform 20 may allow the userto access the newly opened trading account 154 to begin placing tradingorders 152, for example, during the same communication session 148and/or substantially in real time.

For example, suppose a user wishes to open a trading account 154 withtrading platform 20. The user may access one or more web pagesassociated with trading platform 20 via a communications network 100using browser 116 hosted by a client 104 associated with the user, thusinitiating communication session 148. Using the one or more web pagesassociated with trading platform 20, the user may complete anapplication 300 for one or more types of trading accounts 154 withtrading platform 20, which may include entering identificationinformation 302 (such as the user's name, address, telephone numbers,date of birth, and employment information, for example) into variousfields of one or more account application web pages. The accountapplication 300, or at least the identification information 302regarding the user, is then communicated to credit and identityverification module 130 of trading platform 20 (see FIG. 2, arrow A).Credit and identity verification module 130 communicates a creditinformation request 304 to one or more credit verification entities 106to obtain various identity and credit information 308 regarding the user(see FIG. 2, arrow B). The credit information request 304 includes atleast a portion of the identification information 302 received from theuser, as well as an indication 306 of the type of requested creditinformation 308.

In an alternative embodiment, the user's identification information 302may be communicated directly to one or more credit verification entities106 (in other words, without being routed through credit and identityverification module 130 of trading platform 20). For example, aparticular credit verification entity 106 may have an agreement withtrading platform 20 whereby the credit verification entity 106 may beoperable to receive directly from a client 104 (in other words, withoutbeing routed through trading platform 20) a credit information request304 for credit information 308, and the credit verification entity 106may be able to identify from the credit information request 304 that thecredit information request 304 is being made on behalf of tradingplatform 20 and thus retrieve and provide the requested creditinformation 308 to trading platform 20.

The one or more credit verification entities 106 may then retrieve,organize and analyze credit information 308 regarding the user based onthe identification information 302 regarding the user received fromtrading platform 20 (or directly from the user, such as in thealternative embodiment discussed above). For example, a creditverification entity 106 may perform an identity authentication check anda credit check for the user by obtaining identification and creditinformation regarding the user from one or more internal and/or externalelectronic data bases. In particular embodiments, credit verificationentity 106 may perform such identity authentication checks and creditchecks in real time or substantially in real time. The one or morecredit verification entities 106 may then communicate the requestedcredit information 308, including the results of the identityauthentication check and the credit check, to credit and identityverification module 130 (see FIG. 2, arrow C). Such results may includean identity check score 310 and a credit check score 312, as well as oneor more credit information details 314, such as one or more reason codes315, as discussed in greater detail below with respect to FIGS. 3, 4Aand 4B.

At this point, account approval module 132 of trading platform 20determines whether to approve or deny each type of trading account 154applied for by the user based at least on a portion of the creditinformation 308 (in other words, identity check score 310, credit checkscore 312 and/or credit information details 314) received from the oneor more credit verification entities 106. For example, if the userapplied for a credit account, a hybrid deposit/credit account, and astop-loss deposit account, account approval module 132 determineswhether to approve each of these types of trading accounts 154 for theuser. In some embodiments, account approval module 132 applies anapproval decision matrix 170 and an additional set of business rules 180to the credit information 308 received from credit verification entities106 in order to determine whether to approve each type of tradingaccount 154.

Account approval module 132 may then communicate to client 104 viacommunications network 100, such as by e-mail or an appropriate webpage, an approval notification 316 indicating one or more types oftrading accounts 154, shown in FIG. 2 as approved trading account types318, that were approved, or that the user should contact an operator oftrading platform 20 for further instructions (see FIG. 2, arrow D). Theuser may then make and communicate to trading platform 20 a selection ofone or more of the approved trading account types 318, shown in FIG. 2as selected trading account type 320, that the user wishes to be opened(see FIG. 2, arrow E). The user may communicate such selection totrading platform 20 by sending an e-mail or by selecting the one or moredesired types of trading accounts 154 from an appropriate web page usingbrowser 116, for example.

Account establishment module 134 of trading platform 20 may then openthe one or more selected trading account types 320 for the user.Supposing the user selected a credit trading account 154 to be opened,account establishment module 134 creates the credit trading account 154for the user, which includes creating a set of account identificationdata 322 for the credit trading account 154. The account identificationdata 322 may include, for example, an account ID, a user ID 324, and auser password 326. In addition, balance management module 136 maydetermine one or more initial balances and/or limits 158 for the newcredit account 154. One or more of such initial balances and/or limits158 may be based at least in part on particular credit information 308received from credit verification entities 106, or may be predeterminedbased on the type of trading account 154 opened for the user. Accountestablishment module 134 may then communicate the user ID 324 and userpassword 326 to the user via communications network 100, such as by ane-mail or an appropriate web page, for example (see FIG. 2, arrow F).

The user may then access the opened credit trading account 154 byentering his or her user ID 324 and/or user password 326 into a loginweb page provided by trading platform 20 (see FIG. 2, arrow G). Once theuser has accessed his or her credit trading account 154, the user maybegin trading activities within trading platform 20, such as makingrequests to place trading orders 152 to buy or sell betting products150, for example.

Betting products 150 may be created and/or managed by product managementmodule 138 at trading platform 20, as discussed above. In someembodiments, product management module 138 may assign an initial orsuggested quote, or “price” to various betting products 150. Inaddition, product management module 138 may determine estimated tickliabilities 354 for buyers and sellers of various betting products 150.In some embodiments, or for some types of betting products 150, productmanagement module 138 may determine one or more estimated tickliabilities 354 for buying each betting product 150 and one or moreestimated tick liabilities 354 for selling each betting product 150,which may or may not be the same risk factors, depending on theembodiment and the particular betting product 150, as previouslydiscussed.

Using the credit trading account 154, the user may make an order request340 to place a trading order 152 to buy or sell a particular bettingproduct 150 (see FIG. 2, arrow H). The user may make such order request340 via communications network 100 during communication session 148. Tomake the order request 340, the user may specify one or more tradingorder parameters 342 that at least partially define the trading order152, such as the underlying betting product 150, the offered quote, or“price,” the unit stake, and the duration for which the user wishes thetrading order 152 to remain open, for example.

Order management module 140 may determine a risk value 332 for therequested trading order 152, which may represent the actual or estimatedlikely total loss that the user may experience if the trading order 152is placed and matched (in other words, if the trade is executed). Ordermanagement module 140 may then determine whether to approve the user'srequest to place the trading order 152.

To determine whether to approve the user's request to place the tradingorder 152, order management module 140 may use any suitable methodology,which may include various equations or algorithms, such as describedbelow with reference to FIGS. 5A through 5E, for example. Suchmethodology may be based at least on the risk value 332 for therequested trading order 152 and one or more initial balances 158 and/orcurrent balances 160 associated with the user's trading account 154.

In some embodiments, order management module 140 determines an amountavailable for trading 620 in the relevant trading account 154 based atleast on one or more initial balances 158 and/or current balances 160associated with the trading account 154. Order management module 140 maythen compare the amount available for trading 620 in the user's tradingaccount 154 with the risk value 332 for the requested trading order 152to determine whether to approve the requested trading order 152. Ordermanagement module 140 may then communicate a notification 344 to theuser indicating that the user's trading order 152 was placed, such as bye-mail or an appropriate web page (see FIG. 2, arrow J).

Trade management module 142 may then match the user's trading order 152with another trading order, shown in FIG. 2 as trading order 152′, toexecute a trade. Trade management module 142 may communicate anothernotification 346 to the user indicating that the user's trading order152 has been matched (in other words, that a trade has been executed),such as by e-mail or an appropriate web page (see FIG. 2, arrow K).

In addition, trade management module 142 may notify balance managementmodule 136 that the trading order 152 was matched. Balance managementmodule 136 may then adjust one or more current balances 160 in theuser's credit trading account 154 by an amount equal to the risk value332 determined for the user's trading order 152, which may affect theamount available for trading 620 in the user's trading account 154. Theuser may continue to make requests 340 to place additional tradingorders 152 (see FIG. 2, arrow L), which will generally be approved solong as current amount available for trading 620 in the user's tradingaccount 154 is greater than or equal to the risk value 332 determinedfor each trading order 152.

As new trading orders 152 are requested, placed, and matched over time,product management module 138, order management module 140, and balancemanagement module 136 may cooperate to manage, or update, the risk value332 of each betting product 150, the unit stake and/or risk value 332 ofeach trading order 152, and various current balances 160 associated withthe trading account 154.

It should be understood that the particular operations, actions, orcommunications, the order of such operations, actions, or communication,as well as the types of messages or communications, described above withreference to FIG. 2 are provided merely to illustrate various exampleembodiments. Any other suitable operations, ordering of such operations,and types of communications may be used without departing from the scopeof this disclosure.

FIG. 3 illustrates one embodiment of an approval decision matrix 170that may be used to make account approval determinations for prospectiveusers of trading platform 20. Approval decision matrix 170 comprises anidentity authentication section 172, a credit check section 174, and anapproval decision section 176, and indicates approval decisions forvarious types of trading accounts 154 for nine different scenarios orprospective users 178.

Identity authentication section 172 and credit check section 174 includevarious identity check scores 310 and credit check scores 312,respectively, received from one or more credit verification entities 106regarding the various prospective users 178. For example, as discussedabove, trading platform 20 may communicate a credit information request304 to a particular credit verification entity 106 for creditinformation 308 regarding a prospective user attempting to open atrading account 154, for example. The credit information request 304 mayinclude identification information 302 submitted by the prospectiveuser, such as by entering such information into various fields in a webpage associated with trading platform 20. Based on this identificationinformation 302, the credit verification entity 106 may retrieve creditinformation 308 regarding the person identified by the identificationinformation 302 from one or more internal or external electronicdatabases, such as post office databases, utility databases, voterregistration rolls, and bank account databases, for example. Based onthis retrieved credit information 308, credit verification entity 106may calculate and return to trading platform 20 a credit check score 312representing a level or quality of credit associated with the personidentified by the identification information 302, as well as an identitycheck score 310 representing a level of assurance that the personidentified by the identification information 302 by credit verificationentity 106 is the same person as the prospective user.

The identity and credit check scores 310 and 312 received from creditverification entity 106 may be divided into score categories. Forexample, as shown in FIG. 3, the identity check score 310 may be dividedinto three categories, namely Identity Score A, Identity Score B, andIdentity Score C. Suppose a credit verification entity 106 (such asEXPERIAN, for example) returns identity check scores 310, on a scalefrom 0 to 90. For the purposes of approval decision matrix 170, suchidentity check scores 310 may be assigned as follows: identity checkscores 310 greater than or equal to 70 are classified under IdentityScore A, identity check scores 310 greater than or equal to 40 but lessthan 70 are classified under Identity Score B, and identity check scores310 less than 40 are classified under Identity Score C. Similarly, thecredit check score 312 may be divided into three categories, namelyCredit Score A, Credit Score B, and Credit Score C. For example, supposea credit verification entity (such as EXPERIAN, for example) returnscredit check scores 312 on a scale from 300-1200. For the purposes ofapproval decision matrix 170, such credit check scores 312 may beassigned as follows: credit check scores 312 greater than or equal to1000 are classified under Credit Score A, credit check scores 312greater than or equal to 700 but less than 1000 are classified underCredit Score B, and credit check scores 312 less than 700 are classifiedunder Credit Score C.

Approval decision section 176 includes the approval decision for each ofa variety of types of trading accounts 154 offered by trading platform20 based on the identity check score 310 and credit check scores 312 forthe particular scenario or prospective user 178. In the embodiment shownin FIG. 3, the types of trading accounts 154 offered by trading platform20 comprise a large credit account (such as a credit account with creditlimit 602A of $2,000), a small credit account (such as a credit accountwith credit limit 602A of $500), a deposit account, and a stop-lossdeposit account. In some embodiments, trading platform 20 does not offera stop-loss account. It should be understood that trading platform 20may offer, and thus approval decision section 176 may include, anyvariety of suitable types of trading accounts 154.

Approval decision section 176 also includes an entry entitled “CallTrading Exchange” which represents a decision to notify the prospectiveuser that he or she may call an operator of trading platform 20 to askquestions or to submit additional identification or credit information.Thus, as shown in the right side of approval decision section 176, inscenarios 6 through 9 in which the prospective user is denied each typeof trading account 154, the prospective user may be directed to call anoperator of trading platform 20 for further instructions.

As shown in FIG. 3, prospective users may be approved for zero, one, ormore than one type of trading account 154 provided by trading platform20. For example, according to approval decision matrix 170, prospectiveuser number “2” is approved for a small credit account, deposit accountand stop-loss deposit account, but not approved for a large creditaccount. As discussed above with reference to FIG. 1, account approvalmodule 132 may notify prospective users, such as via e-mail or anappropriate web page, the particular types of trading accounts 154 forwhich they are approved and/or denied. Each prospective user may thenselect, such as using a browser application 116, one or more of theapproved types of trading accounts 154 to be opened.

In some embodiments, making approval determinations may also includeprocessing various credit information details 314 received from one ormore credit verification entities 106. In some instances, such creditinformation details 314 may supplement or override decisions that wouldresult from applying approval decision matrix 170 to the identity checkscore 310 and credit check score 312 for a particular prospective user.

One or more credit verification entities 106 may communicate creditinformation details 314 along with the identity check score 310 and/orcredit check score 312 to trading platform 20. Such credit informationdetails 314 may comprise information used by the credit verificationentity 106 in determining a particular identity or credit check score310 or 312. For example, a credit verification entity 106 maycommunicate to trading platform 20 one or more “reason codes” 315indicating various information used in determining the identity checkscore 310 and/or credit check score 312 for a particular prospectiveuser.

FIGS. 4A and 4B illustrate an example embodiment of a rules set 180regarding credit information details 314 received from creditverification entities 106 for use in conjunction with approval decisionmatrix 170 to make account approval determinations. Rules set 180includes a rules classification table 182, an identity check rules table184, and a credit check rules table 186. Rules classification table 182identifies three classifications of rules (A, B and C) used in identitycheck rules table 184 and credit check rules table 186, and adescription of the relevance of each classification of rules. Identitycheck rules table 184 lists a number of relevant reason codes 315 thatmay be received from a credit verification entity 106 regarding theidentity check performed for prospective users, a short description ofthe rule corresponding to each reason code 315, a full description ofthe rule corresponding to each reason code 315, and a rulesclassification for each reason code 315. The relevance of the rulesclassification corresponding to each reason code 315 is provided inrules classification table 182. Similar to identity check rules table184, credit check rules table 186 lists a number of relevant reasoncodes 315 that may be received from one or more credit verificationentities 106 regarding the credit check performed for prospective users,a short description of the rule corresponding to each reason code 315, afull description of the rule corresponding to each reason code 315, anda rules classification for each reason code 315. Again, the relevance ofthe rules classification corresponding to each reason code 315 isprovided in rules classification table 182.

To illustrate the operation of rules set 180 along with approvaldecision matrix 170, suppose for example that for a particularprospective user, a credit verification entity 106 communicates totrading platform 20 an identity check score 310 of 45, a credit checkscore 312 of 850, and a credit check reason code 315 labeled RR32.According to the example categories for identity and credit check scores310 and 312 discussed above, the identity check score 310 of 45 wouldcorrespond with the Identity Score B category, and the credit checkscore 312 of 850 would correspond with the Credit Score B category.Applying approval decision matrix 170, this example falls under scenarionumber “5,” and according to approval decision section 176, theprospective user would be approved for a small credit account, a depositaccount and a stop-loss deposit account. Next, rules set 180 may beapplied to the received credit check reason code 315 labeled RR32.According to credit check rules table 186, the reason code 315 labeledRR32 is a Class A rule that, according to rules classification table182, will not affect the approval decisions made according to approvaldecision matrix 170.

However, suppose that for the same prospective user, the creditverification entity 106 communicated to trading platform 20 the sameidentity check score 310 (45), credit check score 312 (850), and creditcheck reason code 315 (RR32), but additionally communicated identitycheck reason code 315 labeled RR11. Applying approval decision matrix170, this second example still falls under scenario number “5”. However,applying rules set 180 produces a different result. According toidentity check rules table 184, the identity check reason code 315labeled RR11 is a classification B rule and therefore, according torules classification table 182, the prospective user cannot qualify fora credit account. Thus, although the prospective user would be approvedfor a small credit account according to approval decision matrix 170,this approval is overridden by the application of rules set 180 to thereceived identity check reason code 315 labeled RR11. Thus it can beseen that credit information details 314, such as reason codes 315,received from credit verification entities 106 may be used to supplementand/or override various decisions resulting from applying approvaldecision matrix 170.

FIGS. 5A though 5E illustrate an example methodology, as well as theapplication of the methodology for a variety of scenarios, fordetermining whether to approve a requested trading order 152. It shouldbe understood that any other suitable methodologies may be used to makesuch determinations without departing from the scope of this disclosure.

FIG. 5A illustrates a set of current balances equations 500 that may beused to determine or manage various current balances 160 for eachtrading account 154 in accordance with one embodiment of the presentinvention. In some embodiments, current balances equations 500 may beused by order management module 140 in order to manage various currentbalances 160.

FIG. 5B illustrates an credit check decision matrix 510 for determiningwhether to approve a particular user's request to place a particulartrading order 152 in accordance with one embodiment of the presentinvention. In some embodiments, order management module 140 may usedecision matrix 512 to make such determinations. Credit check decisionmatrix 510 comprises six example credit check equations 512 which may beused by order management module 140 to determine whether to approve orreject the user's request to place the trading order 152. Credit checkequations 512 numbered 1, 2, 4 and 6 comprise comparisons between one ormore various current balances 160 associated with a trading account 154and the risk value 332 of the requested trading order 152. Credit checkequations 512 numbered 3 and 5 comprise equations to determine whethervarious current balances 160 are greater than zero. Row 514 indicatesthe determination of whether to approve or reject a requested tradingorder 152 based on credit check equations 512 for nine differentscenarios.

FIG. 5C illustrates an example margin call decision matrix 520 which maybe used by order management module 140 to determine whether a margincall is appropriate in accordance with one embodiment of the presentinvention. Margin call decision matrix 520 includes a first section 522,a section 524 and a third section 526. First section 522 comprises threeexample margin call equations 528 which may be used to determine whetherto make a margin call for a trading account 154 based on various currentbalances 160 associated with the trading account 154. Second section 524indicates the appropriate level of the margin call, or whether no margincall is appropriate, based on margin call equations 528 for sixdifferent scenarios. For example, according to scenario 6, if the user'savailable cash balance 600B is greater than or equal to zero, the user'savailable credit balance 602B is less than zero, and the sum of theuser's available cash balance 600B and available credit balance 602B isgreater than or equal to zero (see section 522), a margin call for theamount of the user's available cash balance 602B is appropriate (seesection 524).

Third section 526 of matrix 520 indicates a method for determining theamount available for trading 620 in a user's trading account 154 basedon margin call equations 528 for each of the six different scenarios.For example, for scenario 2, the amount available for trading 620 in theuser's trading account 154 is equal to the greater of (1) zero and (2)the minimum of (a) the sum of the available waived margin balance 604Band the available cash balance 600B and (b) the available total marginbalance 606B. In one embodiment, if amount available for trading 620determined in section 526 of matrix 520 is greater than or equal to therisk value 332 for the requested trading order 152, the requestedtrading order 152 will be approved. Thus, section 526 of matrix 520 maycomprise a summary of credit check decision matrix 510 shown in FIG. 5B.

FIGS. 5D and 5E illustrate a table 540 showing the determination ofwhether to approve or decline a request to place a trading order 152, aswell as whether a margin call is appropriate, for eight examplescenarios in accordance with one embodiment of the present invention.Row 542 indicates the risk value 332 for the requested trading order152. In this example, the risk value 332 for the requested trading order152 is $3,000 in each scenario. Section 544 illustrates various initialbalances 158 for each scenario. Section 546 illustrates various currentbalances 160 for each scenario. Section 548 illustrates variousintermediate calculations based on various initial balances 158 andcurrent balances 160 for each scenario.

Section 550 illustrates the application of each of the six credit checkequations 512 from check decision matrix 510 (see FIG. 5B) based on therisk value 332 for the requested trading order 152 and various currentbalances 160 and intermediate calculations shown in sections 546 and548. Row 552 indicates the resulting decision of whether to approve orreject the request to place the trading order 152 based on theapplication of the credit check equations 512 for each of the eightscenarios. Section 554 illustrates the application of the margin callequations 528 from margin call decision matrix 520 (see FIG. 5C) foreach of the eight scenarios. Row 556 indicates the resulting margin calldecision and amount determined based on the margin call equations 528for each scenario.

Row 558 indicates the amount available for trading 620 in each scenariodetermined using the methodology shown in section 526 of matrix 520.Thus, as discussed above, if amount available for trading determined insection 526 of matrix 520 is greater than or equal to the risk value 332for the requested trading order 152 (here, $3,000), the requestedtrading order 152 will be approved (which is consistent with the creditcheck results shown in row 552 of table 540.

FIG. 6 illustrates an embodiment of an account database 190 comprisingany number of trading accounts 154 used in trading platform 20. Accountdatabase 190 includes for each trading account 154: an account ID, auser name, a user ID 324, a user password 326, each initial balance 158,each current balance 160, the type of trading account 154 (for example,credit, deposit, or stop-loss account), a list of open trading orders152 (such as a list of order IDs, for example), and a list of executedtrades. Account database 190 may be hosted by or separate from databaseserver 122, and may be accessed by core servers 120 and/or one or moreoperator terminals 110 in order to store, update and/or retrieveinformation regarding various trading accounts 154.

FIG. 7 illustrates an embodiment of an open order database 192comprising any number of open trading orders 152 placed on tradingplatform 20. Open order database 192 includes for each open tradingorder 152: an order ID, a user ID 324 of the user who placed the tradingorder 152, a product ID identifying the betting product 150 upon whichthe trading order 152 is based, whether the trading order 152 is a buyor sell order, the offered price (which may comprise the price per unitof the betting product 150, or the total price of the trading order152), the stake or number of units included in the trading order 152,the risk factor 330 per unit of the betting product 150, the risk value332 of the trading order 152, the time the trading orders 152 wasplaced, and the priority of the trading order 152 (in relation to otheropen trading orders 152). Like account database 190, open order database192 may be hosted by or separate from database server 122, and may beaccessed by core servers 120 and/or one or more operator terminals 110in order to store, update and/or retrieve information regarding varioustrading orders 152.

FIG. 8 illustrates one embodiment of a method for receiving anapplication 300 for a trading account 154 from a prospective user oftrading platform 20, determining whether to approve the application 300,and opening the approved trading account 154 for the prospective user.At step 200, a prospective user accesses a web page for completingand/or submitting an application 300 for a trading account 154 withtrading platform 20, thus establishing a communication session 148between trading platform 20 and a client 104 associated with theprospective user. For example, the prospective user may click on a linkentitled “Apply for an Account” from the home web page of tradingplatform 20. The prospective user may be presented with an accountapplication 300 that may include one or more web pages, each includingone or more information fields.

At step 202, the prospective user enters identification information 302into various fields in the one or more account application web pages. Inone embodiment, the account application 300 comprises a series of webpages in which the prospective user enters identification information302, such as personal information, address information, employmentinformation, and financial information. A “crumbtrail” may be presentedto the prospective user such that the prospective user knows which stepof the account application process he or she is in. At step 204, theprospective user is presented with the terms and conditions of tradingplatform 20. The prospective user accepts the terms and conditions andsubmits the account application 300, such as by clicking on a “SubmitApplication” link.

At step 206, credit and identity verification module 130 receives theprospective user's application 300, or at least the prospective user'sidentification information 302 extracted from the application 300, andcommunicates a request 304 to a credit verification entity 106 forcredit information 308 regarding the prospective user. The creditinformation request 304 may include some or all of the prospectiveuser's identification information 302. At step 208, the creditverification entity 106 retrieves and analyzes various creditinformation 308 regarding the prospective user based on theidentification information 302 regarding the prospective user receivedfrom trading platform 20. Credit verification entity 106 may calculate acredit check score 310 as well as an identity check score 312 for theprospective user based on the retrieved credit information 308 regardingthe prospective user. In addition, credit verification entity 106 mayorganize one or more credit information details 314 regarding theprospective user.

At step 210, the requested credit information 308 (in other words,credit check score 310, identity check score 312, and credit informationdetails 314) is communicated to trading platform 20 via communicationsnetwork 100. In some embodiments, steps 206 through 210 may be performedin real time or substantially in real time. For example, steps 206through 210 may be performed in less than or about 60 seconds.

At step 212, account approval module 132 determines whether to approveeach of one or more types of trading accounts 154 provided by tradingplatform 20. Such types of trading accounts 154 may include, forexample, a deposit account, a large credit account, a small creditaccount, and a hybrid credit/deposit account. In particular embodiments,these determinations may be made as described above in greater detailwith reference to FIGS. 1-4B. If each type of trading account 154provided by trading platform 20 is denied by account approval module 132for the prospective user, account approval module 132 may notify theprospective user of the rejected account application 300 viacommunications network 100, such as by e-mail or an appropriate web pageat step 214. Alternatively, if one or more types of trading accounts 154are approved by account approval module 132 for the prospective user,account approval module 132 communicates to the prospective user anapproval notification 316 indicating the approved account type or types318, at step 216. This approval notification 316 may be made by ane-mail or an appropriate web page communicated to the prospective uservia communications network 100, for example.

At step 218, the prospective user may select his or her desired type oftrading account 154, referred to as the user's selected trading accounttype 320, from the one or more of the approved accounts types 318. Forexample, the approved account types 318 may be presented to theprospective user by an appropriate web page, and the prospective usermay use a pointer to choose the selected trading account type 320 andclick on a “Submit” link to submit the selection to trading platform 20.Alternatively, the approved account types 318 may be presented to theprospective user and/or the prospective user may choose the selectedtrading account type 320 via email communications.

At step 220, balance management module 136 may present the prospectiveuser with a web page offering the prospective user an option to addfunds to his or her trading account 154 using an online credit cardtransaction. If the prospective user accepts the offer, such as byclicking on an “Add Funds” link, balance management module 136 mayprovide the user an interface (such as a series of web pages, forexample) for adding funds to his or her trading account 154 using anonline credit card transaction at step 222.

Alternatively, if the prospective user declines the offer to addadditional funds by credit card, such as by clicking on a “Do Not AddFunds” link, the method proceeds to steps 224. At step 224, accountestablishment module 134 may present the user with an explanation orinstructions for trading online via trading platform 20. Step 224 isshown in parallel with steps 226 and 228 since step 224 may be performedat least partially simultaneously with steps 226 and 228. For example,steps 226 and 228 may be performed as the user reviews the explanationor instructions presented to the user at step 224. At step 226, accountestablishment module 134 opens and/or activates the user's tradingaccount 154, such as described above with reference to FIG. 1. This mayinclude creating a set of account identification data 322, which mayinclude an account number and password. At step 228, accountestablishment module 134 communicates the account number and password tothe user via communications network 100, such as by an e-mail or anappropriate web page, for example.

At step 230, the user receives the account number and password for thenewly-opened trading account 154. In particular embodiments in which theaccount number and password are communicated to the user by e-mail, theuser may keep his or her web browser 116 open, obtain the receivedaccount number and password from the user's e-mail application, andreturn to the web browser application 116 in order to access thenewly-opened trading account 154. For example, this may be possible in aWINDOWS™ or other suitable environment in which multiple applicationsmay be running simultaneously.

At step 232, the user accesses his or her trading account 154 using thereceived account number and password. For example, the user may enterthe account number and password into a login web page for tradingplatform 20 and click on a “Login” button or link. The user may nowbegin trading activity using trading platform 20 at step 234, such asresearching betting products 150 and placing trading orders 152 to buyor sell such betting products 150 via trading platform 20.

In this manner, trading platform 20 may receive an online application300 for a trading account 154, determine whether to approve one or moretypes of trading accounts 154 provided by trading platform 20, notifythe prospective user of the results of such determinations, receive aselection from the prospective user of the desired type of tradingaccount 154 to be opened, open the selected type of trading account 154for the prospective user, and provide the prospective user access to thenewly-opened trading account 154. In some embodiments, the accountapplication 300 may be received from a prospective user, tradingplatform 20 may determine whether to approve each of one or more typesof trading accounts 154 provided by trading platform 20, the determinedresults may be communicated to the prospective user, a desired type oftrading account 154 may be selected by the prospective user, and tradingplatform 20 may open and/or activate the selected type of tradingaccount 154 for the prospective user, all during the same communicationsession between trading platform 20 and a client 104 associated with theprospective user, such as communication session 148 shown in FIG. 1, forexample. In other words, in some embodiments, some or all of steps 200through 226 may be performed during the same communication session.

In addition, in particular embodiments, trading platform 20 maycommunicate an account number and password for the newly-opened tradingaccount 154 to the user, the user may receive the account number andpassword, and the user may access his or her newly-opened tradingaccount 154 using the account number and password all during the samecommunication session between trading platform 20 and client 104 inwhich the prospective user submitted the account application 300. Inother words, in such embodiments, some or all of steps 200 through 232may be performed during the same communication session. Further, inparticular embodiments, the user may also begin trading activity, suchas placing trading orders 152, during the same communication session. Inother words, in such embodiments, some or all of steps 200 through 234may be performed during the same communication session.

Thus, trading platform 20 may receive an application 300 from aprospective user for a trading account 152, determine whether to approvethe trading account 152, open the approved trading account 152, andallow the user to begin trading activities using his or her new tradingaccount 152, all during a single communication session and/or in arelatively short period of time. Thus, the prospective user need notmail any information (such as identification information or creditinformation, for example) to trading platform 20 when applying fortrading account 152 (which may comprise a credit account or an accountincluding a credit component, for example), which is commonly requiredby previous account providers. As a result, the prospective user doesnot have to experience the significant delays associated with openingaccounts with traditional account providers, such as delays associatedwith mailing information to or from the account provider.

FIG. 9 illustrates one embodiment of a method for trading bettingproducts 150 via trading platform 20. It should be understood that themethod shown in FIG. 9 may continue directly from the method shown inFIG. 8. Thus, in particular embodiments, one, some, or all of the stepsshown in FIG. 9 may be performed during the same communication sessionbetween trading platform 20 and client 104 (such as communicationsession 148 shown in FIGS. 1 and 2, for example) as one, some, or all ofthe steps shown in FIG. 8.

At step 250, a user having a trading account 154 with trading platform20 accesses his or her trading account 154 using an account number andpassword, such as described above with reference to step 232 of FIG. 8,for example. At step 252, the user makes a request to place a particulartrading order 152 to buy or sell a particular betting product 150. Torequest the trading order 152, the user may interface with browserapplication 116 to specify one or more parameters which at, leastpartially define the trading order 152, such as the underlying bettingproduct 150, the offered quote or “price,” the unit stake to be wagered,and the duration for which the user wishes the trading order 154 toremain open, for example.

At step 254, order management module 140 determines a risk value 332 forthe requested trading order 152, such as described above with referenceto FIG. 1. At step 256, order management module 140 determines whetherto approve the user's request to place the trading order 152. In someembodiments, this determination may be based at least on one or morecurrent balances 160 in the user's trading account 154 and the riskvalue 332 determined for the trading order 152. For example, ordermanagement module 140 may use the methodology described above withreference to FIGS. 5A through 5E to determine whether to approve or denythe request to place the trading order 152.

If order management module 140 denies the request to place the tradingorder 152, order management module 140 may notify the user of the denialat step 258, such as by an e-mail or an appropriate web pagecommunicated to the user via communications network 100, for example.The user may then continue trading activity at step 260, such as bymaking a request to place other trading orders 152.

Alternatively, if order management module 140 approves the trading orderrequest at step 256, order management module 140 may place the tradingorder 152 on trading platform 20 at step 262. In addition, ordermanagement module 140 may notify the user at step 264 that the orderrequest was approved and the order was placed, such as by e-mail orcommunicating an appropriate web page to the user via communicationsnetwork 100, for example.

If another trading order 152 exists or is placed which matches theuser's trading order 152, trade management module 142 may match the twotrading orders 152 to execute a trade at step 266, such as describedabove with reference to FIG. 1. At step 268, trade management module 142may notify the user that his or her trading order 152 has been matched(in other words, that a trade has been executed), such as by e-mail oran appropriate web page.

At step 270, balance management module 136 may adjust one or morecurrent balances 160 associated with the user's trading account 154 byan amount equal to the risk value 332 determined for the user's tradingorder 152 at step 254. In some embodiments, balance management module136 may update the amount available for trading 620 in the user'strading account 154 as a result of the updated current balances 160.

At step 272, order management module 140 may determine whether to updateany of the user's remaining unmatched trading orders 152 based on theupdated current balances 160 and/or amount available for trading 620 inthe user's trading account 154. For example, order management module 140may determine whether to reduce the unit stake of particular unmatchedtrading orders 152 based on the risk value 332 of each unmatched tradingorder 152 and the amount available for trading 620 in the user's tradingaccount 154, as discussed above with reference to FIG. 1.

The user may continue trading activities at step 260, which may includeany variety of activities, such as making requests to place additionaltrading orders 152, for example. At step 274, the user may make arequest to place another trading order 152. The method may return tosteps 254 through 272 in order to determine whether to approve therequest, place the order, and make the appropriate updates as discussedabove.

In some embodiments, the user may place a particular trading order 152on more than one market at the same time. In addition, in someembodiments, the user may place more than one different trading order152 at the same time, and on one or more different markets.

At step 276, order management module 140 may update the risk factor 330of one of the user's executed trading orders 152. For example, productmanagement module 138 may update the risk factor 330 of the bettingproduct 150 underlying the executed trading orders 152 to account for achange in the so-far of the betting product 150, and order managementmodule 140 may update the risk value 332 accordingly.

At step 278, balance management module 136 may update one or morecurrent balances 160 and/or the current amount available for trading 620in the user's trading account 154 based at least on the updated riskvalue 332 for the executed trading orders 152.

At step 280, order management module 140 may determine whether to cancelor adjust the unit stake of each of the user's unmatched trading order152 based at least on the updated current balances 160 and/or updatedamount available for trading 620 in the user's trading account 154.

For example, if the updated risk value 332 for any of the user'sunmatched trading orders 152 is now greater than the current amountavailable for trading 620 in the user's trading account 154, ordermanagement module 140 may cancel (or at least put on hold) thatunmatched trading order 152. Alternatively, order management module 140may reduce the unit stake for any such unmatched trading order 152 suchthat the risk value 332 for that trading order 152 is less than or equalto the current amount available for trading 620 in the user's tradingaccount 154. The user may continue trading activities at step 282, whichmay include any variety of activities, such as making requests to placeadditional trading orders 152, for example.

FIG. 10 illustrates an example of trading platform 20 acting as anintermediary between users involved in a trade, in accordance with anembodiment of the present invention. As discussed above regarding FIG.1, in some embodiments, trade management module 142 is generallyoperable to allow trading platform 20, or trading engine 114, to act asan intermediary or agent between various users having trading accounts154 with trading platform 20. For example, when trading orders 152 for aparticular betting product 150 are matched (in other words, when a tradeis executed), trade management module 142 may be operable to establishfinancial obligations and execute transactions between trading platform20 and each user involved in the executed trade.

For example, as shown in FIG. 10, suppose a first user, User A, makes arequest to place a first trading order 152A to trade a particularbetting product 150 at a first quote, or “price.” Further suppose that asecond user, User B, makes a request to place a second trading order152B to trade the same betting product 150 at a second quote, or“price.” The requests to place trading orders 152A and 152B may bereceived in any order and at any time relative to each other. Ordermanagement module 140 determines whether to approve each trading order152A and 152B and places each approved trading order 152A and/or 152B ina respective queue 144 on trading platform 20, such as described abovewith reference to FIGS. 1 and 9.

Assuming both first and second trading orders 152A and 152B wereapproved and placed on trading platform 20, trade management module 142may determine whether to match first trading order 152A with secondtrading order 152B based at least on the quote or price of first tradingorder 152A and the quote or price of second trading order 152B, as wellas the positions of trading orders 152A and 152B in their respectivequeues with other trading orders 152 for the particular betting product150.

In some embodiments, trade management module 142 may match first tradingorder 152A with second trading order 152B if the quote or price of firsttrading order 152A is equal to or within a predefined amount of thequote or price of second trading order 152B (assuming no other tradingorders 152 are higher queued to be matched with first or second tradingorders 152A and 152B). In other embodiments, trade management module 142may match first trading order 152A with second trading order 152B if thequote or price of first trading order 152A and the quote or price ofsecond trading order 152B differ by more than or equal to apredetermined amount. For example, trade management module 142 may onlymatch a trading order 152 to sell a particular betting product 150 at aparticular quote or price with a trading order 152 to buy that samebetting product 150 at a quote or price greater than the sell quote orprice by a predetermined amount, such as 4 points, for example. Thus,using the example 4 point differential, trade management module 142would only match an order to sell a betting product at a quote or priceof 32 points with an order to buy that same betting product at a quoteor price of 36 points or higher. In still other embodiments, trademanagement module 142 may match first trading order 152A with secondtrading order 152B if the quote or price of first trading order 152A andthe quote or price of second trading order 152B differ by less than orequal to a predetermined amount.

When trade management module 142 matches trading order 152A with tradingorder 152B to execute a trade, trade management module 142 may establishobligations, such as business, contractual and/or financial obligations,between trading platform 20 and each of User A and B. For example, asshown in FIG. 10, trade management module 142 may establish a first setof one or more contractual or financial obligations 360 between tradingplatform 20 and User A, and a second set of one or more contractual orfinancial obligations 362 between trading platform 20 and User B. Thefirst set of obligations 360 may be established based at least on theparameters of first trading order 152A, including the underlying bettingproduct 150, the quote or price, the unit stake, and the associated riskvalue 332 (which may be determined by order management module 140, asdiscussed above). Obligations 360 may include contractual or financialobligations between User A and trading platform 20 to transfer fundsand/or credit between User A and trading platform 20 based at least onfirst trading order 152A and the potential results of the one or moreevents (such as a sporting event or tournament, for example) associatedwith the betting product 150 underlying first and second trading orders152A and 152B. For example, obligations 360 may include obligations totransfer funds and/or credit between User A's trading account 154A andplatform account 155 based on the parameters of first trading order 152Aand the potential results of the one or more events associated with thebetting product 150 underlying first and second trading orders 152A and152B.

Similarly, the second set of obligations 362 may be established based atleast on the parameters of second trading order 152B, including theunderlying betting product 150, the quote or price, the unit stake, andthe associated risk value 332. Obligations 362 may include contractualor financial obligations between User B and trading platform 20 totransfer funds and/or credit between User B and trading platform 20based at least on second trading order 152B and the potential results ofthe one or more events (such as a sporting event or tournament, forexample) associated with the betting product 150 underlying first andsecond trading orders 152A and 152B. For example, obligations 362 maycomprise obligations to transfer funds and/or credit between User B'strading account 154B and platform account 155 based on the parameters ofsecond trading order 152B and the potential results of the one or moreevents associated with the betting product 150 underlying first andsecond trading orders 152A and 152B.

As or after the event or events associated with the betting product 150underlying first and second trading orders 152A and 152B occur, trademanagement module 142 may receive the results of such event or events.Trade management module 142 may then execute transactions betweentrading platform 20 and each involved user, Users A and B, based atleast on these results. For example, as shown in FIG. 10, trademanagement module 142 may execute a first transaction 364 between UserA's trading account 154A and platform account 155 based on theparameters of first trading order 152A and the results of the one ormore events, and a second transaction 366 between User B's tradingaccount 154B and platform account 155 based on the parameters of secondtrading order 152B and the results of the one or more events.

Transactions 364 and 366 may include, for example, transferring funds orcredit between platform account 155 and each involved user, Users A andB. For example, as shown in FIG. 10, if User A and User B place tradingorders 152A and 152B to trade a particular betting product 150 regardinga cricket match, and User B is victorious (based on the results of thecricket match), trade management module 142 may execute a firsttransaction 364 transferring a first amount 368 of funds or credit fromUser A's trading account 154 to platform account 155, and a secondtransaction 366 transferring a second amount 370 of funds or credit fromplatform account 155 to User B's trading account 154. Trading platform20 may determine first amount 368 based at least on obligations 360between User A and trading platform 20, and second amount 370 based atleast on obligations 362 between User B and trading platform 20. In somesituations, first amount 368 and second amount 370 are the same amount.In other situations, first amount 368 and second amount 370 aredifferent amounts. For example, trading platform 20 may retain as profita difference in amount between first amount 368 and second amount 370.

In some embodiments, trade management module 142 may executetransactions 364 and 366 independently such that each transaction doesnot depend on the execution of the other. Thus, for example, if firstamount 368 is not transferred from User A's trading account 154A toexchange account 155, trade management module 142 may still executetransaction 366 to transfer second amount 370 from exchange account 155to User B's trading account 154B.

In this manner, trading platform 20 may act as an intermediary foreffecting transactions between various users, such as the example UsersA and B. In addition, although trade management module 142 createsobligations 360 and 362 and executes separate transactions 364 and 366with each User A and B, it may appear to each User A and B that thatuser, User A or B, is transacting directly with the other user, User Bor A, respectively. Thus, it may be said that trade management module142 effectuates a “virtual” transaction, indicated in FIG. 10 astransaction 372 between Users A and B involved in the executed trade.

As discussed above with reference to FIG. 1, although in someembodiments trading platform 20 or trading engine 114 may act as anintermediary or agent between users, in other embodiments tradingplatform 20 allows users to trade directly with each other, includingestablishing financial obligations directly with each other.

FIG. 11 illustrates an example method of using trading platform 20 as anintermediary between users involved in a trade in accordance with anembodiment of the present invention. FIG. 11 may be best understood inconjunction with FIG. 10.

At step 400, trading platform 20 receives a request from User A to placea first trading order 152A to buy a unit stake of a particular bettingproduct 150 regarding a football match at a first quote or price. Atstep 402, order management module 140 approves the request from User Aand places first trading order 152A on trading platform 20. At step 404,trading platform 20 receives a request from User B to place a secondtrading order 152B to sell a unit stake of the particular bettingproduct 150 regarding the football match at a second quote or price. Atstep 406, order management module 140 approves the request from User Band places second trading order 152B on trading platform 20.

At step 408, trade management module 142 matches (partially or fully,depending on the respective unit stakes of trading orders 152A and 152B)trading order 152A with trading order 152B to execute a trade. At step410, trade management module 142 establishes one or more contractual orfinancial obligations 360 between trading platform 20 and User A basedat least on the parameters of first trading order 152A and the potentialresults of the football match. At step 412, trade management module 142establishes one or more contractual or financial obligations 362 betweentrading platform 20 and User B based at least on the parameters ofsecond trading order 152B and the potential results of the footballmatch.

At step 414, the football match underlying the particular bettingproduct 150 occurs. At step 416, the results of the football match arecommunicated to trading platform 20. At step 418, trade managementmodule 142 executes a first transaction 364 between User A's tradingaccount 154A and platform account 155 based on the parameters of firsttrading order 152A and the results of the football match. For example,supposing based on the results of the football match that User B issuccessful on the bet, trade management module 142 may transfer a firstamount 368 of funds or credit from User A's trading account 154 toplatform account 155.

At step 420, trade management module 142 executes a second transaction366 between User B's trading account 154B and platform account 155 basedon the parameters of second trading order 152B and the results of theone or more events. For example, again supposing that User B wassuccessful on the bet, trade management module 142 may transfer a secondamount 370 of funds or credit from platform account 155 to User B'strading account 154.

As discussed above, first and second amounts 368 and 370 may be based atleast on obligations 360 and 362 and the results of the football match.In addition, first and second amounts 368 may be the same or differentamounts. Also, as discussed above, steps 418 and 420 may be executedindependently such that execution of each transaction 364 and 366 doesnot depend on the execution of the other.

Although embodiments of the invention and their advantages are describedin detail, a person skilled in the art could make various alterations,additions, and omissions without departing from the spirit and scope ofthe present invention as defined by the appended claims.

1. A method of providing an account, comprising: receivingidentification information associated with a user during a communicationsession; communicating a request for credit information, the requestincluding at least a portion of the identification information;receiving the requested credit information; approving an account basedat least in part on the received credit information; opening theaccount; and providing access to the opened account during thecommunication session.
 2. The method of claim 1, wherein the account isat least in part a credit account.
 3. The method of claim 1, wherein thereceived credit information comprises a credit score and approving theaccount comprises approving the account based at least in part on thecredit score.
 4. The method of claim 1, wherein the received creditinformation comprises a credit score and one or more credit informationdetails and approving the account comprises approving the account basedat least in part on the credit score and the credit information details.5. The method of claim 4, wherein approving the account comprisesapplying one or more business rules to the credit information details.6. The method of claim 1, wherein the received credit informationcomprises an identity score and a credit score and approving the accountcomprises approving the account based at least in part on the identityscore and the credit score.
 7. The method of claim 6, wherein approvingthe account comprises applying a decision matrix to the identity scoreand the credit score.
 8. The method of claim 1, further comprising: foreach of a plurality of different types of accounts, determining whetherto approve that type of account based at least in part on the receivedcredit information; communicating a notification indicating each of theapproved types of accounts; and receiving a selection of one of theapproved types of accounts; wherein opening the account comprisesopening the selected type of account.
 9. The method of claim 1, furthercomprising: during the communication session, receiving a request toplace a first order to trade a product, the request being made using theopened account; and placing the first order.
 10. The method of claim 9,wherein the first order is defined at least in part by a plurality oforder parameters, the method further comprising determining whether toapprove the request to place the first order based at least in part onone or more of the order parameters.
 11. The method of claim 10, furthercomprising: determining one or more balances for the account based atleast in part on the received credit information; and whereindetermining whether to approve the request to place the first order isbased at least in part on one or more of the order parameters and one ormore of the determined balances for the account.
 12. A system forproviding an account, comprising: a processor operable to: receiveidentification information associated with a user during a communicationsession; communicate a request for credit information, the requestcomprising at least a portion of the identification information; receivethe requested credit information; approve an account based at least inpart on the received credit information; open the approved account; andprovide access to the opened account during the communication session;and a memory operable to store the opened account.
 13. The system ofclaim 12, wherein the account is at least in part a credit account. 14.The system of claim 12, wherein: the received credit informationcomprises a credit score; and the processor approves the account basedat least in part on the credit score.
 15. The system of claim 12,wherein: the received credit information comprises a credit score andone or more credit information details; and the processor approves theaccount based at least in part on the credit score and the creditinformation details.
 16. The system of claim 15, wherein the processorapproves the account by applying one or more business rules to thecredit information details.
 17. The system of claim 12, wherein: thereceived credit information comprises an identity score and a creditscore; and the processor approves the account based at least in part onthe identity score and the credit score.
 18. The system of claim 17,wherein approving the account comprises applying a decision matrix tothe identity score and the credit score.
 19. The system of claim 12,wherein the processor is further operable to: determine, for each of aplurality of different types of accounts, whether to approve that typeof account based at least in part on the received credit information;communicate a notification indicating each of the approved types ofaccounts; and receive a selection of one of the approved types ofaccounts; wherein opening the account comprises opening the selectedtype of account.
 20. The system of claim 12, wherein the processor isfurther operable to: receive, during the communication session, arequest to place a first order to trade a product, the request beingmade using the opened account; and place the first order.
 21. The systemof claim 20, wherein: the first order is defined at least in part by aplurality of order parameters; and the processor determines whether toapprove the request to place the first order based at least in part onone or more of the order parameters.
 22. The system of claim 21, whereinthe processor determines one or more balances for the account based atleast in part on the received credit information, and determines whetherto approve the request to place the first order based at least in parton one or more of the order parameters and one or more of the determinedbalances for the account.
 23. A method of providing an account,comprising: electronically receiving credit information regarding auser; approving an account based at least in part on the electronicallyreceived credit information; opening the account; and providing accessto the opened account.
 24. The method of claim 23, wherein the accountis at least in part a credit account.
 25. The method of claim 23,wherein the received credit information comprises a credit score andapproving the account comprises approving the account based at least inpart on the credit score.
 26. The method of claim 23, wherein thereceived credit information comprises a credit score and one or morecredit information details and approving the account comprises approvingthe account based at least in part on the credit score and the creditinformation details.
 27. The method of claim 26, wherein approving theaccount comprises applying one or more business rules to the creditinformation details.
 28. The method of claim 23, wherein the receivedcredit information comprises an identity score and a credit score andapproving the account comprises approving the account based at least inpart on the identity score and the credit score.
 29. The method of claim28, wherein approving the account comprises applying a decision matrixto the identity score and the credit score.
 30. The method of claim 23,further comprising: for each of a plurality of different types ofaccounts, determining whether to approve that type of account based atleast in part on the received credit information; communicating anotification indicating each of the approved types of accounts; andreceiving a selection of one of the approved types of accounts; whereinopening the account comprises opening the selected type of account. 31.The method of claim 23, further comprising: receiving a request to placea first order to trade a product, the request being made using theopened account; and placing the first order.
 32. The method of claim 31,wherein the first order is defined at least in part by a plurality oforder parameters, the method further comprising determining whether toapprove the request to place the first order based at least in part onone or more of the order parameters.
 33. The method of claim 32, furthercomprising: determining one or more balances for the account based atleast in part on the received credit information; and whereindetermining whether to approve the request to place the first order isbased at least in part on one or more of the order parameters and one ormore of the determined balances for the account.